Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html Those bozos are suggesting to reduce MTU from 1500 to 576 to "improve performance", so packets "won't fragment in backbones"! The bright idea to fix CTS/RTS setting didn't come along in their brilliant minds. Here goes the average packet size. Down the drain... Now what do we do to control the damage? I also think it's a good time to measure the gullibilty of the general public by measuring packet size distribution :) --vadim
This is hardly an operational issue. That said, I think CNN messed up their explanation rather than giving wrong advice. Some of the original RFCs for SLIP and PPP, as well as Stevens in TCP/IP Illustrated Volume I, pointed out that lower mtu's on dialup lines could significantly improve latency for interactive traffic while having only a small efficiency loss for data intensive traffic. The key was that you didn't want small high-priority packets to be waiting in a queue while larger full-size mtu packets were being sent. Matt Vadim Antonov wrote:
Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html
Those bozos are suggesting to reduce MTU from 1500 to 576 to "improve performance", so packets "won't fragment in backbones"! The bright idea to fix CTS/RTS setting didn't come along in their brilliant minds.
Here goes the average packet size. Down the drain...
Now what do we do to control the damage?
I also think it's a good time to measure the gullibilty of the general public by measuring packet size distribution :)
--vadim
On Wed, 27 May 1998, Matthew Marlowe wrote:
That said, I think CNN messed up their explanation rather than giving wrong advice.
I don't think so. They even said in their article that the technical details are based upon this URL http://www.sns-access.com/%7Enetpro/maxmtu.htm and this guy says stuff like: And, it turns out, depending on how your ISP and other routers encountered on the Internet handle your TCP/IP requests, that a MaxMTU setting of 576, often referred to as the "Internet Standard", will in many cases avoid the fragmentation of packets of data and the slow transfer speeds which result.
Stevens in TCP/IP Illustrated Volume I, pointed out that lower mtu's on dialup lines could significantly improve latency for interactive traffic while having only a small efficiency loss for data intensive traffic.
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? -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
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?
Yes, and like Karl said things work better with the smaller MTU (like it or not). Adjusting other TCP parameters is also a good idea on your servers (although things are better now, *nix boxes of a few years ago just weren't tuned to be used with 14.4 and 28.8 modems). bye, ken emery
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.
On Wed, May 27, 1998 at 03:13:53PM -0700, Vadim Antonov wrote:
Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html
Those bozos are suggesting to reduce MTU from 1500 to 576 to "improve performance", so packets "won't fragment in backbones"! The bright idea to fix CTS/RTS setting didn't come along in their brilliant minds.
Here goes the average packet size. Down the drain...
Now what do we do to control the damage?
I also think it's a good time to measure the gullibilty of the general public by measuring packet size distribution :)
--vadim
Yes, doing this really does work, and really does improve performance - for Win95. The reason it does has nothing to do with fragmentation (they got that part wrong); the reason has to do with poor handling of larger packets in the IP stack and what I can only consider to be bugs in their code. Cut the MTU, get rid of the problem, and the system "seems" faster on the Internet. The reason is that you aren't dropping frames on the floor any longer. Does it suck in REALITY for the network packet size averages? Yes. Does this have anything to do with CTS/RTS and flow control? Nope. Its a genuine, no-bullshit, honest-to-god probelm in the code that is worked around by doing this. Go talk to Mister Softee about the millions of copies of Win95 that are out there IP stacks that make this an "optimization". But until then, expect it to be done, because it really does make the connection work better. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
At 20:15 5/27/98 -0500, you wrote:
Cut the MTU, get rid of the problem, and the system "seems" faster on the Internet. The reason is that you aren't dropping frames on the floor any longer.
Yup. I got an apparent 12% faster connection and reduced packet loss by setting my MTU to 576 (using MTUSpeed, a handy little program).
Does this have anything to do with CTS/RTS and flow control? Nope. Its a genuine, no-bullshit, honest-to-god probelm in the code that is worked
around
by doing this.
The official explanation is that W95 (and W98, as far as I can tell) has packet sizes set to 1500 for Ethernet LAN transmission and uses the same sizes for Internet TCP/IP connections. If you're not on an Ethernet, adjusting the MTU gives you a better 'Net connection. Spam(tm) is pressed meat. Spammers should be too. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]
participants (6)
-
Dean Robb -
Karl Denninger -
ken emery -
Matthew Marlowe -
Michael Dillon -
Vadim Antonov