On Wed, 27 May 1998, Michael Dillon wrote:
Most people are changing the MTU to speed up web browsing which is data intensive, not interactive. I think Karl's explanation of broken Windows TCP/IP stacks is more likely the root cause of the problem.
But has anyone ever done a proper test of this with sniffers at both the client end of the network and the webserver end of the network?
I don't know, but dropped or corrupted large packets is the reliable indicator of the flow control problems on async lines. I saw that million times, and that explanation is a lot more plausible than misterious bugs. The reason why broken flow control affects TCP performance is very simple: most dialup modems have buffers from 2 to 4 kilobytes. Now, given the large disparity in speed of dialup line and the serial port, that buffer limits window size to 2-3 large packets, with single packet lost due to modem buffer overflow every round-trip time. I.e. the steady-mode packet loss is 15-30%. Reducing MTU allows window to grow to 6-10 packets, thus reducing steady-mode packet loss to 3-5%. The real answer is: fix the !#@! CTS/RTS, so the buffering occurs in the host memory. (BTW, the recommendation to reduce MTU to increase interactive performance is only valid when connection is shared between interactive and non-interactive traffic. This is clearly not the case.) --vadim Who still remembers debugging 4800 bps backbone lines.