|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: PMTU-D: remember, your load balancer is broken
> Stephen Sprunk: Wednesday, June 14, 2000 3:48 PM > > Sez <[email protected]> > > The 576 value of the MS PPP MTU is merely a default - it can be > > changed with a registry hack. > > Expecting the tens of millions of novice computer users to set their > systems for a 1500 byte MTU is irrational. Those who are > knowledgeable > enough to do so are generally reducing it due to "speed up your modem" > articles and programs which improve interactive performance at the > expense of throughput. How does this effect the link when the server explicitly sets MTU=512+40, in the server-side of the PPP link? AFAICT, that over-rides whatever the end-user may want to do. > > I thought the frame-size limits for Gigabit Ethernet were > 64-1518/1522 > > bytes? And isn't that the limit on most host IP stacks for Ethernet > media? > There are now several devices on the market that will do > Jumbo frames on > GigE. For instance, the Catalyst 6000 and GSR do: > http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_ 5/cmd_refr/set_po_r.htm#xtocid661812 > I know there are several other vendors who support Jumbo frames as well. > > Finally, I would say that on any medium, <100% utilization in and of > > itself isn't grounds for fiddling with the MTU. There are lots of other > > things to look at, first. Without doing performance analysis on the actual running code, there really isn't a lot else to look at. In my case, we are looking at the web-server<->RDBMS link, which I've already architcted to be on a dedicated switch segment. We already know that we'll never get much less than 3KB data transfers on that bus and it could get as high as 50KB. Larger transfers will also happen, occasionally. Where it hits the WAN is the OPS pipe to the fail-over site. We're looking at that now. > I hear consistent requests from server folks for higher MTUs; they claim > the per-frame CPU hit is significant enough to warrant using Jumbo > frames to increase throughput. The results clearly show that it helps. It isn't really the CPU hit, although that may be a factor, we have intentionally over-built CPU because it's relatively cheap. The problem is that we aren't getting enough CPU utilization, because the xfer rates are too slow. That's how we found the problem in the first place. We've identified the source as being in the ramping algorithms (which make no sense in a switched environment, IMHO). A way to get a faster ramp is to have larger packet sizes to begin with. Since our switch-gear can handle it (all Cisco) the real issue is how this effects the WAN? There are also limits to how much we can tinker with the TCP/IP stacks on the RDBMS machine.
|