*
programming and human factors
by Jeff Atwood
*
We sit at the intersection of two trends:
If that sounds like you, or someone you know, there's one tweak you should know about that can potentally improve your local network throughput quite a bit -- enabling Jumbo Frames.
The typical UDP packet looks something like this:
But the default size of that data payload was established years ago. In the context of gigabit ethernet and the amount of data we transfer today, it does seem a bit.. anemic.
The original 1,518-byte MTU for Ethernet was chosen because of the high error rates and low speed of communications. If a corrupted packet is sent, only 1,518 bytes must be re-sent to correct the error. However, each frame requires that the network hardware and software process it. If the frame size is increased, the same amount of data can be transferred with less effort. This reduces CPU utilization (mostly due to interrupt reduction) and increases throughput by allowing the system to concentrate on the data in the frames, instead of the frames around the data.
I use my beloved energy efficient home theater PC as an always-on media server, and I'm constantly transferring gigabytes of video, music, and photos to it. Let's try enabling jumbo frames for my little network.
The first thing you'll need to do is update your network hardware drivers to the latest versions. I learned this the hard way, but if you want to play with advanced networking features like Jumbo Frames, you need the latest and greatest network hardware drivers. What was included with the OS is unlikely to cut it. Check on the network chipset manufacturer's website.
Once you've got those drivers up to date, look for the Jumbo Frames setting in the advanced properties of the network card. Here's what it looks like on two different ethernet chipsets:
That's my computer, and the HTPC, respectively. I was a little disturbed to notice that neither driver recognizes exactly the same data payload size. It's named "Jumbo Frame" with 2KB - 9KB settings in 1KB increments on the Realtek, and "Jumbo Packet" with 4088 or 9014 settings on the Marvell. I know that technically, for jumbo frames to work, all the networking devices on the subnet have to agree on the data payload size. I couldn't tell quite what to do, so I set them as you see above.
(I didn't change anything on my router / switch, which at the moment is the D-Link DGL-4500; note that most gigabit switches support jumbo frames, but you should always verify with the manufacturer's website to be sure.)
I then ran a few tests to see if there was any difference. I started with a simple file copy.
Default network settings
Jumbo Frames enabled
My file copy went from 47.6 MB/sec to 60.0 MB/sec. Not too shabby! But this is a very ad hoc sort of testing. Let's see what the PassMark Network Benchmark has to say.
Default network settings
Jumbo Frames enabled
This confirms what I saw with the file copy. With jumbo frames enabled, we go from 390,638 kilobits/sec to 477,927 kilobits/sec average. A solid 20% improvement.
Now, jumbo frames aren't a silver bullet. There's a reason jumbo frames are never enabled by default: some networking equipment can't deal with the non-standard frame sizes. Like all deviations from default settings, it is absolutely possible to make your networking worse by enabling jumbo frames, so proceed with caution. This SmallNetBuilder article outlines some of the pitfalls:
1) For a large frame to be transmitted intact from end to end, every component on the path must support that frame size.The switch(es), router(s), and NIC(s) from one end to the other must all support the same size of jumbo frame transmission for a successful jumbo frame communication session.
2) Switches that don't support jumbo frames will drop jumbo frames.
In the event that both ends agree to jumbo frame transmission, there still needs to be end-to-end support for jumbo frames, meaning all the switches and routers must be jumbo frame enabled. At Layer 2, not all gigabit switches support jumbo frames. Those that do will forward the jumbo frames. Those that don't will drop the frames.
3) For a jumbo packet to pass through a router, both the ingress and egress interfaces must support the larger packet size. Otherwise, the packets will be dropped or fragmented.
If the size of the data payload can't be negotiated (this is known as PMTUD, packet MTU discovery) due to firewalls, the data will be dropped with no warning, or "blackholed". And if the MTU isn't supported, the data will have to be fragmented to a supported size and retransmitted, reducing throughput.
In addition to these issues, large packets can also hurt latency for gaming and voice-over-IP applications. Bigger isn't always better.
Still, if you regularly transfer large files, jumbo frames are definitely worth looking into. My tests showed a solid 20% gain in throughput, and for the type of activity on my little network, I can't think of any downside.
Dennis - these things aren't always a cost of time. Computer enthusiasts enjoy discovering and using new technologies, so the time invested is on entertainment rather than work.
`Josh on March 2, 2009 1:14 AMThe biggest problem I have with this now is that over the past few years at home I've gone from a primarily wired-network with one or two wireless devices to a primarily wireless network with a single wired device.
I've only got one desktop that's actively in-use and using a wired ethernet connection anymore. Then a wireless printer, PS3, laptops, iphone and so forth. All still running at 54Mbps, too. And it seems things are transitioning more in that direction than towards gigabit ethernet. At least for at home.
Neil (SM) on March 2, 2009 1:19 AMMost home networking gear, including routers, has safely transitioned to gigabit ethernet.
And how much transitioned to IPv6? That's just as important!
Nicolas on March 2, 2009 1:42 AMI apologise for calling Jeff an idiot the other day. That was uncalled for, unproductive, and makes *me* the idiot. So there.
Very interesting topic,
Not something i'd ever even heard of.
CHeers Jeff
Chris Coffey on March 2, 2009 1:51 AMI'd imagine the bigger packets could be slower on high activity lans due to colisions? It would be interesting to see some testing on that kind of thing. In a realm of gigabit lans though this may have little impact.
rob ryan on March 2, 2009 2:01 AMAnother advantage besides of the lower overhead which results in a higher datarate is the lower CPU usage (fewer interrupts) at the same datarate. This is a big topic in industrial vision systems, where you have GigE cameras with given datarates.
asdrubael on March 2, 2009 2:07 AMThanks Jeff, for the great insight.
With 10Gbps lines all around us, it is good to knwo how to utilise it for all its worth.
Mohit Nanda on March 2, 2009 2:15 AMA network that isn't attached to the internet is like a circular road with no exits - you might be able to set your own rules, but eventually you get sick of the same scenery all the time.
How do you find it affects your performance with internet connections?
Xepol on March 2, 2009 2:36 AMhi
i have been building networks for broadcasters for over a decade - who always wanted bigger / faster / more type networks.
jumbo frames are great in theory, but the pain level can be very high.
A core network switch can be brought to its knees when 9 Kbyte frames have to be fragmented to run out a lower MTU interface.
Many devices dont implement PMTU correctly, or just ignore responses - video codecs seem particularly prone to this.
and wasnt there a discussion a few newsletters ago about dont try to optimise things too much? If you need 20% more network performance, but you are only operating at maybe 40% load, then you need a faster machine or a better NIC card.
And there have been something like 5 definitions of jumbo just in the cisco product line. Also telecomms manufacturers idea of jumbo often have frames with 4 Kbytes, not 9 Kbytes.....
And just to set the record straight - the reason for the 1514 bytes frame limit in GigE and 10G ethernet is backward compatibility.
Just about every network has some 10/100 (or 10 only) equipment still, and the 1514 limit has been built into other standards such as 802.11 wireless LAN.
the old saying is that God would have struggled to make the world in 7 days if he started with an installed base...
Stephen on March 2, 2009 2:38 AMJeff,
I think that your UDP packet schema is wrong.
Ethrnet packet is max 1518 (14 header + 4 trailer + 1500 max payload).
In UDP, payload is divided between IP and UDP headers (20+8) and UDP Paylod.
So the max udp payload is: 1518 - 14 - 4 - 20 - 8 = 1472 bytes.
I think you've made a slight factual error. The total size of the payload of an ethernet frame can be 1500 octets, with 18 octets for the header and crc data. This is the Maximum Transmit Unit, or MTU. That is at the ethernet layer, at the IP layer, which must be fully contained within the ethernet payload, the IP and UDP / TCP headers compete with the body of the packet for the remaining 1500 octets.
http://en.wikipedia.org/wiki/Ethernet#Physical_layer
Any idea if this technique works well on wireless networks (802.11g)
Neil Naidoo on March 2, 2009 3:36 AMYou'd be much better off with a Popcorn hour:
- cheaper
- (extremely) small
- fanless
- it plays ANY media you may have over the net, off your shared drives
- will output at the same frame rate as the source material for judder-free smoothness
- easy to use by your SO
- no OS
- etc.
I have one and I am converted.
Nick++ on March 2, 2009 3:43 AMWireless networks have a lot of transmission errors, so large frames would not work. In any case, Jumbo frames are only useful if the CPU cannot keep up with the data rate. Since wireless networks are quite slow, this is not an issue.
I have not enabled Jumbo frames on my network and probably never will, because I have some PCs that have 100mbps NICs (and do not need faster ones). If I enabled Jumbo frames, I would have to put a router between the gigabit and 100m parts of my network so that it can fragment the packets. I will just use gigabit NICs with TCP segmentation offloading suport :)
Pentium100 on March 2, 2009 3:48 AMI did some of this myself recently. I ended up getting intel nics for all the boxes, everything works much better. also, with tcp there is some ability to negotiate frame sizes so some mix/match can work.
however, I tossed all my nics that have the 1k/2k...7k sizes - it just didn't work too well, in the case of my Myth box, not at all!
plus, with linux you may need to do some tuning to get things running smoothly.
nrf
nrf on March 2, 2009 4:01 AMThere are too many pitfalls. I've gone down this road before, and it is painful, and yet, I do the same as you so you've got me thinking that maybe I should try it again.
You've listed many of the problems but the comments have listed more. (non jumbo devices, internet, etc). I'm willing to bet you a beer that after a while of dealing with the nuisances, you're just going to say F it and put settings back to default. (Those settings are supposed to be there for people like us, but they're really a bit more like a Dickensian toy shop)
Actually, maybe the ideal solution lies in one of the more recent trends in MB design/layout: multiple ethernet NICs onboard. If the number of machines that you truly run large files between is small (as is mine), run a small, exclusive (maybe even all-the-same-NIC), parallel network.
The problem is that even a simple solution like that takes time and money to setup, it complicates your network a good bit, and I'd argue it is far in excess of the slightly longer time you incur by using defaults and thus guarantee everything just works. It's a problem that is probably unnecessarily optimized.
Most home networking gear, including routers, has safely transitioned to gigabit ethernet.
Not for wireless connections it hasn't.
You supply the caveat of technically, for jumbo frames to work, all the networking devices on the subnet have to agree on the data payload size, but make no mention of JF being unsupported by wireless connections.
Most home connections at present have at least some wireless components - these wireless connections are almost invariably on the same subnet as any wired connections.
Your suggestion is likely to cause a lot of slightly-informed people grief as they attempt to eke a little more performance out of their networking gear, without knowing WTF they are doing.
Mark on March 2, 2009 4:23 AMI'm glad Nicolas mentioned IPv6, as that is much more relevant here than jumbo frames. If I'm not mistaken, IPv6 requires devices to use Path MTU Discovery, so jumbo frames would largely be a non-issue.
Bob Somers on March 2, 2009 5:29 AMMost home networking gear is gigabit? Really? I'd like to see where you're drawing the statistics for that. Even if the average home user is keeping on the leading edge of home network routers and ethernet cards (instead of the economy class offerings of older technology), how many of them are going to know to go get the latest drivers from the *chipset* manufacturer? Or to go in and change the default settings of anything, let alone the obscure depths of network card settings?
My gut reaction based on my personal experience is that gigabit is still a few years off for the typical home user. But I'm willing to be proven wrong if you've got some studies...
RS Reitz on March 2, 2009 5:46 AMJust a couple things to point out.
File transfer is typically done using TCP, not UDP. TCP has more overhead than UDP.
I'm curious why we see a sawtooth pattern in the un-jumbo framed graph. Is that TCP Vegas doing its thing?
I'm glad you've gone ahead and tried this out. Jumbo frames wouldn't exist if they didn't have a purpose, but with all the different kinds of traffic I think 1500 MTU is a good choice.
One with jumbo frames that you touched on, but didn't adequately explain, is that most consumer switches use the store-and-forward method of switching packets. This means that your switch must receive the whole packet before it can send it along, it can't be doing anything else because packets can't be multiplexed. This can cause unacceptable latency (you have 2 computers, not a big deal, but between several machines all trying to send data, you can end up with some seriously delayed packets).
I just would have liked to see more reasons not to do this that it's not a supported standard and doesn't work with a lot of hardware. There are other reasons this has not become the default.
Nick on March 2, 2009 6:10 AMMost home networking gear, including routers, has safely transitioned to gigabit ethernet.
You can't really be serious...
Maybe I'd believe it if you said Most ubertechie's home networking gear...yadda yadda yadda.
Matt on March 2, 2009 6:22 AMDenton Gentry has it right. We're always trying to wring the maximum out of our data-video network (mixed Irix-Windows), and some years ago GigE + jumbo frames were like magic bullets on the network segments that could handle it, easily giving a 50-60% boost.
With so much legacy 100base gear, and switches that didn't understand jumbos, it took a long time before everything was integrated (you don't just replace a 200+ port switch every day). In key places we have dual 1000base NICs, one talking to the jumbo-capable segments, and one to the legacy segments. But with IRQ-coalescing NICs, and offloaded CSum etc, the difference is much less than 50% now.
And of course, our high-performance segments have migrated to Infiniband, and 10GigE is around the corner. It never stops.
Mack on March 2, 2009 7:08 AMSwitches can just up and drop the jumbo frame packets? When this happens, do they send back a failure message?
Timothy on March 2, 2009 7:49 AMJumbo frames are fan-friggin-tastic for clustering. I'm speaking of the now ancient kind where you have shared SCSI drives and crossover cables. I'll assume everyone else has moved out of the 1990s.
All other drawbacks as noted in the comments are true for home networking. If you don't have an internal network specifically for data transfer, you're going to find edge cases all over the place.
SteveJ on March 2, 2009 8:14 AMAssuming that many of these fast home networks are using FiOS, I'll point out that FiOS requires a 1492 MTU.
twmcneil on March 2, 2009 8:17 AM@Bob from what I have seen IPv6 is potentially a bigger problem than IPv4, because where an IPv4 router may see that the packet is too large and fragment it, IPv6 leaves it to the end devices.
Allen on March 2, 2009 8:18 AMWhat an apropos article, I'm setting up an iSCSI SAN this week (with HBAs and jumbo frames, of course).
In addition to these issues, large packets can also hurt latency for gaming and voice-over-IP applications.
That's why you should use a dedicated network. The problem isn't the large packets themselves, it how they play with the smaller, more numerous real-time packets when traversing the network equipment.
This is the Jeff that I fell in love with. Welcome back buddy!
Steve-O on March 2, 2009 9:13 AMWhile jumbo frames are very useful when transferring large files, they are basically incompatible with networks that require a lot of low latency packets.
The upcoming IEEE 802.1av standard for Audio/Video Bridging specifically disallows jumbo frames since a single jumbo frame would starve the high bandwidth low latency streams and also induce unacceptable jitter in the packet times.
--jeffk++
I'd heard of this while browsing the Drobo app store where there's a Jumbo Frames app ( http://www.drobo.com/droboapps/downloads/index.php?id=10 ), but hadn't investigated what it was exactly. Thanks for the writeup!
Adam on March 2, 2009 10:15 AMI'd be interested to see what would happen to your internet connection throughput if you enable jumbo frames. My understanding is that packet fragmentation is seriously bad news for performance, if you're trying to send through anything that doesn't support the large packet size.
Nathaniel on March 2, 2009 10:36 AMAnother nay here; I gave up on jumbos.
1. One switch I use lies through its teeth, and handles jumbos badly.
2. You WILL see a CRC failure every now and then with 9k frames. May you be a lucky b*stard and have it happen only in the middle of a pr0n you don't care about.
3. If *any* of your gigabit NICs are PCI-slot, rather than PCIe or Motherboard-PCIe, fugghedaboutit. You won't get the boost, and CPU will go up.
4. Some of the latest drivers (are you listening, Marvell?) aren't worth spitting at.
5. If all of the above don't dissuade you from a 20-30% speed boost combined with pain, go ahead, brave man.
-chicken
@Allen That's the benefit of how IPv6 handles it though. No fragmentation, no messing with frame sizes. The endpoints discover the maximum MTU for their transmission path and use without having to configure anything. ;)
Bob Somers on March 2, 2009 11:36 AMJeff, did this 20% speed bust worth the time you invested into researching that issue and reconfiguring these settings?
I think I will get these Jumbo Frames (or whatever) couple of years later without spending any of my time on that -- just because I would install new OS or something like that.
Dennis Gorelik on March 2, 2009 12:37 PMSomething interesting I learned (and I still believe it to be true, but I wouldnt be surprised if modern network tech can negate it):
Minimum packet length ~= Maximum network segment
This is to prevent two distant stations from transmitting on the same network segment, writing the complete packet and not listening for a collision, and then having the two packets collide in the middle of the segment.
(Min packet length) x (Network speed e.g. 100Mbps) x (line transmission speed) = Maximum network length
JMJ on March 3, 2009 1:07 AMFun.
Practicality on March 3, 2009 6:50 AM20% is so much that the gain can't be blamed on the packet overhead. The difference in packet overhead between jumbos and regular frames isn't even 1%. I bet that the difference is in the TCP window back-off.
Looking at the two graphs, I see that the max throughput is about the same for both. The regular frames, however, backoff farther down that the jumbo frames. That is what is killing performance, IMHO.
If you have a way to monitor TCP window size over time I bet that you'll see the difference in the graphs. If the connection is relatively free of noise you could also increase the retransmit time-out to improve performance. You could run Wireshark and snoop out a few TCP packets to get a feel for the TCP window size over time.
Eyal on March 3, 2009 7:52 AMit is absolutely possible to make your networking worse by enabling jumbo frames, so proceed with caution
Yes! this is so true. Our previous network admin royally screwed up the network by doing this on some but not all switches.
@JMJ
AFAIK you're right on classic/old ethernet network: hub and/or coaxial calble (10Mbit). If you use switches (and not hubs) the collision domain is reduced to two point: you and the switch. The switch uses internal buffer and every port is a collision domain.
fabrizio
fabrizio on March 3, 2009 11:28 AMYes, Jumbo Frames do rock. Disk speed over the wire. Hard to get all your drivers and cards to support it though:
http://www.hanselman.com/blog/WiringTheHouseForAHomeNetworkPart5GigabitThroughputAndVista.aspx
Yes but what about WoW...well this help me pwn Undead Rouges?
Ryan on March 4, 2009 3:03 AMJumbo Frames made a HUGE difference for throughput on my home network. I went from 30'ish MB/sec to roughly 50MB/sec. The only downside is I game a lot and this can cause more latency. I enabled it on my other vista-64 box and my home server and they xfer much better now (I'm not using JF on my gaming rig). Great read!
Doug
Douglas Rohm on March 4, 2009 4:17 AMThe most interesting thing about this is the very low usage of the network capacity.
60MB/s*8bits = 480Mbits/s
Not counting the SMB (Windows networking) header, the ethernet/IP/UDP only accounts for an additional 3% (or less for jumbo frames)
The problem is Window's SMB protocol. You can get typically get DOUBLE the speed (i.e. a 100% improvement) using FTP, which is much better than the 26% improvement Jeff achieved using Jumbo frames.
Andrew on March 4, 2009 12:07 PMJumbo frames are great. I work on VMware ESX networking, and I will point out what may not be obvious to everyone. In a virtualized environment (hosted or hypervisor) jumbo frames make an even bigger difference, since you are doing more work per packet to begin with. That's why we added jumbo frame support since ESX 3.5 shipped.
My experience is that any recent machine can easily push full 1Gbit line rate (on native, and for that matter ESX VMs). Setting Jumbo Frames will save you on CPU though, which will allow you to run more VMs or otherwise use that power. And while Jumbo Frames are nice- they get you from 1.5k packets to 9, TCP Segmentation Offloading (TSO) is much better, since you push down entire 64k (or sometimes up to 256k) packets, and an engine on the NIC itself automatically handles dicing them into 1.5K packets. Most good nics support this- Intel, Broadcom, etc. On the other side, the reverse is LRO, or RSS, but this is more complicated and less common. Plus with TSO, you don't have to worry about MTU.
The other thing I would mention is- for the love of god, don't run networking benchmarks by doing a file copy. With 1GBit networks, you are limited by your disk speed! Run a proper tool such as iperf (brain dead simple) or netperf, which just blasts data. Even if your hard drive could reach 1Gbit speeds, you would be wasting cycles, so your networking performance would be worse. You always want to look at these things in isolation.
Randy Robertson on March 5, 2009 1:12 AMSorry.. as I read more misinformed posts, I feel the need to lay down more truth.
The reason that all these people are seeing performance improvements using Jumbo Frame on Windows is because Windows networking stack sucks. Windows is really stupid and often will not let a single tcp stream reach the full capacity of the NIC. I.e. you run 1 TCP stream and measure 400Mbits, but if you ran 3 in parallel you would hit 940Mbits (~Line rate). This is even more annoying with 10G, since you need like 18 streams to reach the peak performance. Linux doesn't have these problems, and will give you its best possible performance on a single stream. I can only imagine Window's behavior is the result of some misguided attempt at ensuring fairness between connections by making sure that even if there is only one connection, it never uses the full capacity.
Randy Robertson on March 5, 2009 1:19 AMI recently went gigabit. What a letdown. True, copying 5gb dvd images became much faster but otherwise I don't notice it.
To add insult to injury, I had to turn OFF jumbo frames on my gaming PC because the online lag/latency was horrible.
Mr. Bill on March 5, 2009 2:48 AMIf 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.
Craig on March 5, 2009 7:34 AMPardon 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?
If you are using Vista/W7 in a workgroup, or in a domain with Server 2008, its SMB 2.0 is much much faster.
David Moisan on March 6, 2009 10:42 AMOfftopic, but those plots are fine example of something i see a lot these days - plots marked with scales using weird numbers. Not tic marks at neat numbers like 0, 300, 350, 400, (thousands, whateve) but at 371, 424, ..? Not just on web pages; oddball scales appear on stock price plots on PBS' Nightly Business Report, for example.
Was some badly written plot drawing code released into the wild for eveyone to use? Is this some cutting edge trend i'm not up on? A government conspiracy designed to make little boys like ask questions?
DrunkenUFOPilot on March 9, 2009 3:40 AMOfftopic #2. Totally agree how useless charts are with 'random' scale values. Makes it impossible to tell at a glance the nature of the data based on the shape of the curve.
Glenn on March 9, 2009 8:39 AMa highly related article
SMB 1 vs 2, w/ and w/o jumbo frames... initiation of transfer on each side, cpu usage and various other windows networking issues.
this article was great BTW.
forgot URL:
a href=http://www.alternativerecursion.info/?p=48http://www.alternativerecursion.info/?p=48/a">http://www.alternativerecursion.info/?p=48/a">http://www.alternativerecursion.info/?p=48http://www.alternativerecursion.info/?p=48/a
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:
1. 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.
2. 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.
Denton Gentry on February 6, 2010 11:13 PMThe latency drawback is overstated.
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.
Eamon Nerbonne on February 6, 2010 11:13 PMifconfig will show the MTU in linux. You can change the size from the 1500 default (or automatic) to a specific with Gnome NetworkManager applet.
anon on February 6, 2010 11:13 PM@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.
Denton Gentry on February 6, 2010 11:13 PMcheap Yves Saint Laurent Jujube
Yves Saint Laurent Tribute Sandal in Dark Blue
Yves Saint Laurent Tribute Sandal in Chestnut
This is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email
Posted by: |