|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MAE-EAST Moving? from Tysons corner to reston VA.
On Sat, 17 Jun 2000, RJ Atkinson wrote: > At 22:46 16/06/00 , Richard A. Steenbergen wrote: > > The common number that all > >those using jumbo frames should support is 9000 bytes (not 9k aka 9216). > > Disagree, for the reasons described in RFC-1626. The IP MTU > described in RFC-1626 has a number of advantages for hosts > using TCP, whether or not NFS is in use. That came out wrong, my point was that the number on all jumbo frame implementations should be no lower then 9000 bytes, not that this is the best possible number. Optimizing for NFS seems to be one of the lowest considerations on the list of important things though. :P > >This would probably need to be a condition of using GigE at the NAP, > >in order to achieve any kind of common support, and you're eliminating > >some vendor gige support (assuming their network can even carry the 9k > >packets TO the nap without requiring even more work and possible > >problems). > > Virtually all GigE vendors already do support the ~9K size > I've been talking about. Some don't, we've already found a couple on this list. That fact aside, several OS drivers for GigE NICs do not currently support jumbo frames. > POS has a configurable MTU. One could easily reconfigure one's POS > interfaces to have a ~9K MTU. The point is that unless everyone makes these changes, any attempt to run a higher MTU along a non-supporting path without a reliable PMTU-D mechanism will result in bloody horror. > The real number ought to be >= 9180 IP bytes + Ethernet overhead, > so that hosts can do page-flipping and other optimisations. > Without Jumbo-grams, neither NT nor any common UNIX can run full > line-rate over TCP/IP with GigE today. With Jumbo-Grams, both > NT and UNIX can achieve 1 Gbps of throughput over TCP/IP/GigE. I've been able to get DAMN NEAR line rate with sendfile(2) zero-copy transfer, and some optimizations for the entire packet output path, using FreeBSD and some AMD K7 800s, without using jumbo frames. It would certainly help to be doing less packets/rateoftime though, as this is a (the?) major bottleneck. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
|