How to optimize your DSL broadband performance with Jumbo Frame support
In my last article on “Why BitTorrent causes so much latency and how to fix it“, I talked a little about packet sizes and some people asked me what the optimum packet size for maximum throughput is on a DSL broadband connection. In this article I’m going to show you how to optimize your DSL broadband connection in Windows Vista using the netsh command. I will also show you to find the optimum compromise between a Jumbo Frame LAN and a DSL PPPoE broadband connection.
It turns out that the default 1500 BYTE packet isn’t optimum for DSL PPPoE based broadband connections because of the additional 8-BYTE PPPoE overhead. If you send out maximum size packets using 1500 BYTES, then each packet will fragment in to two packets because it’s too big for the PPPoE DSL connection so you end up with double the packets and double the overhead.
Note that Cable Broadband users don’t need to change this because they don’t need to deal with the PPPoE overhead.
The first thing you need to do is open up a command prompt elevated to administrator. For Windows Vista, you do this by hitting the start button and typing the command “cmd” but don’t hit enter yet. Move your mouse up to the top of the menu and right click on cmd.exe and then left click “Run as administrator”.
The next step is to type or cut-paste the command:
netsh interface ipv4 set subinterface “Local Area Connection” mtu=1492 store=persistent
Note that this assumes you are using your typical default LAN connection which is usually labeled “Local Area Connection” but it could be labeled something else if you have more than one Ethernet port or you relabeled the connection name to something more specific. If it is called something else, then you need to adjust the command above accordingly.
This command takes effect immediately and there is no need to reboot. The “store=persistent” command tells Windows Vista that this is a permanent setting. You can confirm after any reboot with the following command which can be done in a normal console.
netsh interface ipv4 show subinterfaces
Windows XP users can use a tool called DrTCP.
Optimizing for Jumbo Frame and DSL PPPoE Broadband
The 1492-BYTE MTU is optimum for DSL broadband but not optimum for high-speed gigabit LAN. In fact, there are times when you want to use Jumbo Frames to avoid the problematic Vista MMCSS packet per second throttling behavior. But a lot of Jumbo Frame implementations are limited to 4082-BYTE Ethernet Frames. So the trick is to use an MTU size that is a multiple of the broadband-optimized packet. The IP packet is always 28 bytes smaller than the largest MTU so the broadband-optimized IP packet is 1464 Bytes. We multiply that by 2 and we get 2928 so the proper MTU size would be 2956 which is still smaller than 4082. So for users who want to have a good compromise between Jumbo Frames and PPPoE DSL, they can use an MTU of 2956. That means the LAN won’t fragment the packet but the broadband connection will do a clean two-for-one split that results in optimum size packets.
So the command to implement the 2956 MTU would be:
netsh interface ipv4 set subinterface “Local Area Connection” mtu=2956 store=persistent
You can actually test for larger numbers to see if your setup supports larger jumbo frame sizes like 6K or 7K Jumbo Frames. If it does, then you might be able to use an MTU of 5884 which is derived from 4 times 1464 plus 28. Here’s an illustration of how this clean fragmentation works
Verifying Jumbo Frame support
You should verify that you have a switch that supports Jumbo Frames and an Ethernet Adapter in the computer with proper drivers. You can enable Jumbo frames by going to the Control Panel, Network and sharing center, View status, Properties button, Configure button, Advanced tab, Jumbo Frame option.
To verify the whole thing by running the following test between two computers on your LAN that are configured to support Jumbo Frames which we’ll call Computer-A and Computer-B.
On Computer-A, run the following command to verify jumbo frame support.
ping Computer-B-IP-Address -l 4054 -f
Note that “-l” in the command above is a dash lower-case L.
If you get a proper reply without an error message, that means your computers and Ethernet Switch supports 4082-BYTE MTU.
TCP should automatically detect the proper MTU; is that not happening?
Also, AFAIK 100Mbps Ethernet does not support jumbo frames, so what happens when a jumbo frame gets to your router or modem?
What and how much improvement will be seen by performing this? I have DSL, using Vista.
It’s not an OS improvement, it’s broadband speed improvement. You’re effectively sending less overhead and fewer packets per second over the broadband link. It’s probably nothing earth shattering but it is better.
MTU discovery isn’t a sure thing, though the newer OSes should be more reliable. To make it always work correctly, you use clean multiples for your MTU and it will always result in cleanly and evenly chopped packets.
You don’t seem to understand IP, ICMP, and the Don’t Fragment flag. Something is broken in your network if you are fragmenting your packets. Otherwise, your packets destined to/from the Internet will automatically take the size of the smallest MTU in the chain to the remote server, likely the 1492 of your PPPoE. All the time spent figuring out multiples of the hypotenuse are wasted.
Instead, just pick the largest jumbo MTU that works with all your GigE devices and GigE switches/routers. 9000 is frequently used, although not the limit.
Mr. Nutsou, seems you haven’t tested anything because you wouldn’t be talking the way you are if you did. MTU 9000 isn’t supported by many jumbo-frame enabled switches and it isn’t supported by many Ethernet adapters. What I told users to do is to use clean multiples of 1464 and use the largest MTU their equipment supports by TESTING with do-not-fragment flag. It seems like you don’t even understand the illustrations I put up.
George Ou
Mr. Ou,
I understood what you said; what you don’t understand is that it is irrelevant — moot. In fact, in so far as a person uses 1464 as an MTU instead of 1500, they are losing 2.5% of their per-packet performance.
If your local network doesn’t support 9000, then your MTU should be set to 1500 (or the limit of your switch, if it isn’t 1500 or 9000) and forget about it. No need for multiples of anything. IP does it for you, as long as your network isn’t screwed up.
The bottom line is this: The 2nd paragraph of this story is factually incorrect. A 1500 MTU does NOT cause twice as many packets over a 1492 link. IP+ICMP notes there is a link with a smaller MTU in the path, and lowers the MTU on that path accordingly. Result: no fragments.
"In fact, in so far as a person uses 1464 as an MTU instead of 1500, they are losing 2.5% of their per-packet performance."
1464 is the actual payload size; 1492 is the actual MTU because it’s DSL with an 8-byte PPPoE overhead. The fact that you don’t understand this is simply scary.
Second, you’re not losing 2.5% performance between MTU 1500 and MTU 1464. Smaller packets have lower payload to header ratio. The difference in additional overhead is less than .2% difference and if you don’t understand that, go take some basic networking classes.
George Ou