Re: TCP Stall

David S. Miller (davem@jenolan.rutgers.edu)
Sun, 30 Mar 1997 21:50:06 -0500


Date: Sun, 30 Mar 1997 21:35:26 -0500 (EST)
From: "Richard B. Johnson" <root@analogic.com>

Apparently this problem is not considered important
because absolutely nothing has been done about it for
over two years. There have been no experimental patches
from Network gurus attempting to fix this very real and
very troublesome problem.

You may be in for a surprise.

Instead, I see on the "list" much more important ideas
about graphical boot-up and other esoterics.

Please note that the actual developers expressed just as much grief
about that unfortunate thread as you are.

Now, how does the machine that received a window of zero
know that buffers are available again? I watch the Sun
send a SYN. It receives an ACK with the new window. I
don't know if this is the correct thing to do according
to the RFCs, but it works. It is likely that the routing
machine, i.e., the one that has buffers loaded with data,
trying to free them by getting the data squeezed into the
PPP link, should be the machine to send a SYN when
buffers are available again.

There were two sets of bug reports for 2.0.29 and pre2.0.30, one dealt
with the TCP logic incorrectly setting the window to zero when it
should not have, the other was with incorrect Nagle and partial packet
handling.

I believe that Eric Schenk and myself have both addressed these issues
in what will soon be released as the next pre-2.0.30 patch set. I
would be interested if you can still reproduce your problems with that
kernel when it is released.

If you are referring in particular to 2.1.x kernels, Eric and myself
both know that the queueing logic in the TCP stack there is completely
fucked and we plan to work on it heavily, you will need to be a bit
more patient for things to get fixed in 2.1.x's TCP.

---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><