Messages in this thread |  | | | Date | Sun, 30 Mar 1997 21:50:06 -0500 | | From | "David S. Miller" <> | | Subject | Re: TCP Stall |
| |
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 /_____________/ / // /_/ ><
|  |