If you simply enable jumbo frames on your NIC, every connection to any Internet destination (which don’t support jumbos) will need to undergo PMTU discovery, PMTU blackhole detection, router fragmentation, or other time-consuming / performance-sapping hacks. This might explain why people complain about latency issues with gaming. These people are also seeing slightly slower peformance with all Internet activity.
*nix, as/400/, mainframes, and other operating systems let you set the frame size on a per route basis. E.g.,
route add -net 0.0.0.0 gw 192.168.0.1 mss 1460
This tells the OS to use jumbo frames only on the local LAN, and to assume a normal packet size everywhere else.
Alas, Windows has no such ability. One solution on Windows is to use two NICs attached to the same network. Have one NIC configured with normal frames and the default route. Have the second NIC configured for jumbos with no default route.
Pardon the off-topic comment, but in a sense, it’s in place. I think that although this is a technical discussion, I’d prefer working harder at programming and becoming a technical expert about data, interaction, speeds and things like that, rather than blogging about the social aspects or hacking, although I am quite successful for my tiny brain size (hurray!) . Those things are far more fluid than data packets. So in that sense experimenting with Jumbo size packets is not for me. There! Back on topic.
Now there’s another big decision - monkey business or the light of human freedom? Or both? Or the popular second-grade coffee?
I participated in the IEEE 802.3 committee for a while. IEEE never standardized a larger frame size for two reasons that I know of:
The end stations can negotiate the frame size, but there was no backwards-compatible way to ensure that all L2 bridges between them can handle it. Even if you send a jumbo frame successfully, you can still run into a problem later if the network topology changes and your packets begin taking a different path through the network.
The CRC32 at the end of the packet becomes weaker after around 4 KBytes of data. It can no longer guarantee that single bit errors will be caught, and the multibit error detection becomes weaker as well.
One is free to enable it, and it does improve the performance, but the situation is unlikely to ever get better in terms of standard interoperability. It will always be an option to be enabled manually.
Also a number of years ago,. jumbo frames provided a much bigger boost. Going from 1.5K to 9K regularly doubled performance or more. What has happened since is smarter ethernet NICs: they routinely coalesce interrupts, steer packets from the same flow to the same CPU, and sometimes even reassemble the payload of the 1.5K frames back into larger units. The resistance to standardizing jumbo frames resulted in increased innovation elsewhere to compensate.
transmitting 9KB of data, or 72 kilobit, would take 72 microseconds. That’s not problematic latency, and a 1000 times as much still wouldn’t be (for voice, anyhow).
Intuitively, if 1.5KB was OK on 10MB, then the same latency should be achievable with 150KB frames on a gigabit.
Of course we’d also like to capitalize on the increased switching speed so going that far is overkill - but frame-size related latency isn’t something we need to worry about - of course, low latency apps shouldn’t buffer up to a full frame, so there might be a software issue here.
@Timothy Layer 2 ethernet switches will just drop packets they cannot handle. It is not just if they don’t handle jumbo frames: they can drop a normal size packet if their internal queues are full, or if rate limiting has been configured, or if the switch hit some other internal condition which the ASIC designer didn’t bother resolving. They just drop the packet and expect the sender to retransmit. There is no mechanism for an L2 device to send back a notification that it has dropped the packet. A managed L2 switch will have some counters so you can post-mortem analyze what is wrong with your network.
Layer 3 routers will drop packets for more reasons, in addition to queue congestion. For example when the packet is too big and the don’t fragment bit is set, an ICMP message is sent back (this is how path MTU discovery works). Similarly routers send back ICMP messages if they have no route to the destination.
Even the ICMP is just a best effort notification. Routers routinely limit the rate of ICMP messages they will send, to avoid having a flood of ICMP messages make a bad network problem worse. ICMP messages can also be dropped on their way back to the originator. So the best the sender can expect is it might get notified of an L3 problem, sometimes.
Let’s not forget about Ethernet Pause frames, which can help to avoid frames being dropped by switches that have filled up their port buffers. A previous comment suggested there was no layer 2 message to indicate drops, but Pause frames aka xon/off are a layer 2 protocol.
As a point of interest, in 2015 I see about 117 MB/sec of network throughput on gigabit (with jumbo frames enabled, naturally) using a modern router and modern PCs.
That’s almost 2x the 60 MB/sec I measured in 2009!
Humm. I was reading this post to enable Jumbo Frames for my network.
I cannot upload an image here (got an error saying new users cannot upload images). But I constantly get 110 MB/s to 120 MB/s between my desktop and server not doing anything - all using Windows version of networking drivers, and going through 2 Gigabit switches. Everything set to factory MTU 1500.
I haven’t set anything related to Jumbo Frames.
Asus RIVBE mobo - 1 Gbps connection w/Windows 8.1 (Windows drivers for network)
1x Netgear 8 port 1 Gbps switch
1x Linksys 5 port 1 Gbps switch
MSI X58 mobo - 1 Gbps connection w/Windows Server 2012 (Windows default drivers)
(about 150 feet of wiring between them all)
I think Jumbo frames are more for 10 Gbps connections?
. Those things are far more fluid than data packets. So in that sense experimenting with Jumbo size packets is not for me. There! Back on topic. 
