Date: Wed, 17 Apr 2002 11:00:45 -0500 From: Damon Permezel <dap@damon.com> To: Alexander Isaev <A.Isaev@astelit.ru> Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.5 and network problems Message-ID: <20020417160045.GQ343@fubar.damon.com> In-Reply-To: <16114655943.20020417131347@astelit.ru> References: <16114655943.20020417131347@astelit.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Not sure about the initial delays, but I found a bug which does cause
throughput to drop dramatically once it is hit.
Consider the sender of a bulk data transfer (1/2 duplex).
When header prediction is successful, the ACK stream coming back
is handled by the fast path code. For this to be true, the window info
in that ACK stream cannot change.
tiwin && tiwin == tp->snd_wnd
When the window finally does change, we go to the slow path.
There is a check against WL1 and WL2 to ensure that the window update is
not from an earlier packet. The fast-path code does not drag WL1/WL2
along. In this example, only WL2 (the ACK) changes, as the peer is sending
no data. Because WL2 has not been dragged along, the check to see if the
current ACK is "fresh" can fail. I was seeing this all the time with
a gigabit-rate xfer I was using for a test.
Because the slow-path ACKs do not update the window, the snd_wnd closes,
and becomes 0.
Once snd_wnd becomes zero, we end up performing zero-window probes on the
sender. We send one byte. The receiver, meanwhile, has opened his
window up again, and ACKs the byte, with an open window.
The slow-path processing of this ACK will still ignore the window update,
and the following code will set snd_wnd to -1.
if (acked > so->so_snd.sb_cc) {
tp->snd_wnd -= so->so_snd.sb_cc;
sbdrop(&so->so_snd, (int)so->so_snd.sb_cc);
ourfinisacked = 1;
} else {
sbdrop(&so->so_snd, acked);
tp->snd_wnd -= acked;
ourfinisacked = 0;
}
acked was 1, tp->snd_wnd was 0. snd_wnd is unsigned.
We suddenly have a huge send window. Blast away! ... except we end up being
driven by the rexmit timer and slow start, again and again.
I am not really sure what happens in this mode. The activity light on the
link turns out except for brief, intermittent flashes, so I suppose it
rexmits, slow starts, gets going, overruns the window, .....
The snd_wnd keeps being decremented and will, given sufficient time, wrap
down to reasonable values, and this might recover. I have not had the
patience.
There is a simple fix:
if (tp->t_state == TCPS_ESTABLISHED &&
(thflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK &&
((tp->t_flags & (TF_NEEDSYN|TF_NEEDFIN)) == 0) &&
((to.to_flags & TOF_TS) == 0 ||
TSTMP_GEQ(to.to_tsval, tp->ts_recent)) &&
/*
* Using the CC option is compulsory if once started:
* the segment is OK if no T/TCP was negotiated or
* if the segment has a CC option equal to CCrecv
*/
((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) != (TF_REQ_CC|TF_RCVD_CC) ||
((to.to_flags & TOF_CC) != 0 && to.to_cc == tp->cc_recv)) &&
th->th_seq == tp->rcv_nxt &&
tiwin && tiwin == tp->snd_wnd &&
tp->snd_nxt == tp->snd_max) {
/*
* drag along the snd_wl1 and snd_wl2 as we are implicitly
* updating the window with the new (same) value.
*/
tp->snd_wl1 = th->th_seq;
tp->snd_wl2 = th->th_ack;
BTW: I have not made this change to FreeBSD, but to a FreeBSD-derived
embedded network stack, so I can't even assure you that the above
two lines compile (as I had to edit them slightly to recast into the F-BSD
idiom).
Cheers,
Damon.
On Wed, Apr 17, 2002 at 01:13:47PM +0400, Alexander Isaev wrote:
>
> I have installed FreeBSD 4.5. Everything worked OK from the console.
> But when I tried to connect to it remotely (using SSH) I had some network troubles.
> From time to time to time the connection hangs for a short time.
> First of all I've tried to install another network card (I've replaced
> D-Link 550 with D-Link 538TX). But the problem still exists. Later
> I've noticed that network timeouts happen also when sending or
> receiving large files over SMTP/POP3.
>
> Can someone help me to solve this problem?
>
> Best regards,
> Alexander Isaev mailto:A.Isaev@astelit.ru
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
--
--
Damon Permezel
dap@damon.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020417160045.GQ343>