I’ve been doing some research into Ethernet and the use of Jumbo frames for some content I’ve been writing and come across something interesting. A document claims that Jumbo frames can only be used on Full Duplex Ethernet connections.
Jumbo frames were proposed by Alteon in 1998 and later Alteon was acquired by Nortel Networks who produced the first devices to support Jumbo frames.
So I’ve dome some scratching on that itch and not got very many satisfactory answers.
Q. Why do we want jumbo frames ?
A. To improve server performance. How ?
- Larger frames translate into less packet overhead on the server.
- Less packets means fewer interrupts on the server and a smaller CPU load.
- Less interrupts means less delay on the server bus.
- Larger frames provide better buffer utilisation and forwarding performance in switches.
- Less packets means less routing CPU/performance used
- Less packets means less network overhead in terms of headers and frame formats melding to better utilisation.
Let me make some extrapolations based on the available data . Jumbo frames can only be used on full-duplex Ethernet connections because:
- the IEEE 802.2-1998 standard has never adopted or ratified Jumbo frames ( because it’s not backward compatible with existing Ethernet equipment) therefore the use of oversized frames on half duplex connections would be problematic.
- Ethernet in half duplex mode assumes that there is an active shared bus with more than two workstations and therefore the CSMA/CD MAC layer is active and is detecting collisions. Once frames are longer that 1518 bytes, the IEEE 802.2 CSMA/CD would mark these as giant frames and regard them as errors.
Proof ?
Unfortunately, I cannot prove this. I don’t have access to a lab where I could configure this with any level of confidence by setting two switches to half duplex and enabling . For example, to configure this in a hem lab would imply that the server software and hardware network interface was capable for jumbo frames and that the switches were of sufficient quality to be confident that the jumbo frames were working correctly.
Earlier this year, Jason Boche wrote post Jumbo Frames Comparison Testing with IP Storage and vMotion which suggested that IP Storage and Jumbo did not offer a performance benefit for his testing. This is counterintuitive but Jason knows his stuff and is highly trustable, the test is rigorous and his results clearly show limited benefit.
Knowing that half duplex links might cause Jumbo frames to fail would be interesting research – since it’s possible that either the server or the storage array might have be in half duplex mode.
If anyone can test and advise me, I’d be pleased to post the results here.
Postscript
I found this interesting data in the research process.
Q. Why are Jumbo frames 9000 bytes long ?
A. Because the CRC field isn’t long enough to guarantee detection of errors for frames larger than 9000 bytes.1
Response
- http://staff.psc.edu/mathis/MTU/arguments.html – The undetected packet error rate was calculated using the following assumptions: 1- The “raw strength” of the CRC is 1 part in 232. I.e. a single arbitrary burst error will yield a “random” CRC, which will be a false pass once per 4 × 109 packets. Actual CRCs are stronger than this because all errors patterns in some of the more common cases (e.g. single bit errors) can be proven to never cause a false pass. 2- The ability of the CRC to detect a given burst error is not affected by the amount of correct data in the same packet. 3- The probability of there being 2 burst errors in the same packet is low. If this is not the case, you introduce second order terms on both sides of the calculation. 4 – I am in complete agreement that CRC-32 is not strong enough for large data sets. It probably does need to be improved. The CRC issue does not provide an argument for limiting MTU, only that current Ethernet may not be suitable for large data sets. ( Author’s emphasis) ↩
