On Sat, 17 Jun 2000, RJ Atkinson wrote:
Sounds like a filter on which product one buys. :-)
Based on those who don't support a non-standard extension? At any rate, people will buy them, and problems will ensue. :P
That fact aside, several OS drivers for GigE NICs do not currently support jumbo frames.
Which OSs don't yet support this ?
Not OS, drivers. Pick your favorite OS with GigE support, grep jumbo the drivers section. In a few cases the unix drivers support jumbo frames and the reference vendor drivers do not, in a couple its the other way around. I see its getting better though, there is more support then there used to be the last time I looked.
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.
For content replication, as differentiated from content distribution, the larger MTU should be safe. A larger than 1518 MTU won't be safe for content distribution anytime soon because the Cable Modem standards specify a 1518 MTU and cable modems are a leading way to provide high performance networking to homes.
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.
Curious. sendfile(2) is using TCP ? Any TCP extensions present ? This was off-the-shelf FreeBSD ? Which version ? Which GigE card (NetGear GA-620 ?) ?
Based off 4.0-STABLE, using some work I'm doing on the FreeBSD TCP/IP stack (mainly cleaner code and a few trivial optimizations at this point, nothing earth shattering), some additional optimizations and shortcuts through the stack based on IP Flow which I'm writing, using back to back NetGear GA620s, 512k send/recvspace buffers and a 1MB socket buffer, and a really quick in-kernel ack & discard in the receiving end. The last time I tried it with standard userland transfers was on back to back p3 500s which pulled about 450Mbps between a GA620 and an Intel GE.
It would certainly help to be doing less packets/rateoftime though, as this is a (the?) major bottleneck.
Packet processing overhead and memory manipulation are generally the bottlenecks in hosts. There is substantial literature to this effect.
Isn't that the truth. I think of a lot of it is poorly optimized and well-planned code though. -- Richard A Steenbergen <ras@e-gerbil.net> 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)