Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Optimising MTU setting in PPPoE ADSL Connections Network
I use PPPoE on an ADSL connection which is limited only by the modem sync speed (ie: no data rate capping by the ISP, on the downstream at least), and I wanted to optimise the MTU to get the best throughput. The consensus seems to be that the optimal MTU is 1454, based on the fact that 1492 the maximum possible, and 1454 is the highest value less than this which doesn't end up with any padding bytes in the last ATM cell. An ATM cell is the basic transfer unit over a DSL link, and they are all fixed length, padded out to this length if the packet doesn't end on a cell boundary.

I tried configuring the 1454 value using a couple of techniques mentioned on macosxhints, but they didn't seem to have much effect, at least not on the downstream packets. A little network tracing showed that Mac OS X PPPoE was still negotiating an MTU of 1492 with my ISP. So I did a little digging around and came up with the following solution...

The PPP configuration is stored in the following property list file:
/Library/Preferences/SystemConfiguration/preferences.plist
Open this with your preferred text file editor. Note that you need root access for this -- see appropriate macosxhints on using sudo. Also make sure you save a copy first, and use a genuine text editor like vi or pico, not a word processor.

WARNING: You could easily make your system unbootable if you corrupt this file, so make sure you know what you're doing!

Search down for the PPP section -- it's introduced by this line:
<Key>PPP</Key>
Immediately following this, you will see an indented list of PPP properties. You need to insert two new parameters as follows (insert the appropriate value if you want something other than 1454):
<key>LCPMRU</key>
  <integer>1454</integer>
<key>LCPMTU</key>
  <integer>1454</integer>
I kept mine in alphabetical order, so after the edit my file reads:
.....
<Key>LCPEchoInterval</Key>
  <integer>10</integer>
<key>LCPMRU</key>
  <integer>1454</integer>
<key>LCPMTU</key>
  <integer>1454</integer>
<key>Logfile</key> 
  <string>/var/log/ppp.log</string>
....                               
Yours may differ, of course, depending on what properties are listed.

Save the file, and then restart your Mac (there's probably a neater way of causing the system to re-read the file, but I don't know what it is...) and connect to the internet. In my case, I consistently measured an increase in download speed of around 7-8KBytes/sec. Hardly worth writing home about, but it's nice to know that none of the ADSL modem speed is being wasted.

This tip works on 10.4 at least, but I haven't tried it on earlier versions.
    •    
  • Currently 2.80 / 5
  You rated: 3 / 5 (5 votes cast)
 
[24,956 views]  

Optimising MTU setting in PPPoE ADSL Connections | 13 comments | Create New Account
Click here to return to the 'Optimising MTU setting in PPPoE ADSL Connections' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Optimising MTU setting in PPPoE ADSL Connections
Authored by: davidkisley on Aug 26, '05 09:52:11AM

it is importatant to remember that not all adsl providers use ATM. Or at least will not in the future, so testing before and after is very important. i work for a large DSL provider, and our current network supports this, but our next generation nework will use gig e optical links to aggragate DSLAMS, which will have a different optimal MTU.

---
Powerbook G4 1GHZ 15.1



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: wontz on Aug 26, '05 11:41:46AM

I also work for an ISP. The transport between the modem and the DSLAM is always done using ATM cells. This true for ADSL, ADSL2 and ADSL2+ protocol.

It's true that many large ISPs also use ATM for backbone (we don't). But since ATM remains from the house to the Central Office, 1454 will remains a good value.



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: cahaddras on Aug 26, '05 07:25:48PM

It doesn't really matter whether the ISP uses ATM or not on its own network. ATM is used on the ADSL link regardless, otherwise it wouldn't be ADSL. However it's certainly true that there are variants on how PPPoE is carried over ADSL. For example, LLC/SNAP may be used instead of VCMux for carrying the ethernet packet over the ATM Virtual Connection, adding a further 8 or 12 bytes to the packet. So the optimal MTU may be different and it is worth experimenting.



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: jeffbyrnes on Aug 26, '05 12:06:16PM

Just to let everyone know, there is a built-in GUI method for altering the MTU of an ethernet network connection; if you open the Network prefs pane, double click on built-in ethernet, then click the ethernet tab on the far right. The "Configure" menu will say "Automatically", change it to "Manually", then you'll see a few options appear, one of which is "Maximum Packet Size (MTU)". Click the "Custom" radio buttom, and type in 1492. Click Apply Now, and enjoy.

---
-Jeff



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: cahaddras on Aug 26, '05 07:04:59PM

This works fine for communicating directly over ethernet, but unfortunately makes no difference to the MTU value negotiated on a PPPoE connection. This is arguably a bug, as when PPPoE is configured under Mac OS X, direct communication over ethernet is no longer available (unless you configure it down at the UNIX level). So it would be appropriate that if the ethernet MTU is configured in network preferences when PPPoE is enabled, then this should set the PPPoE MTU instead, but it doesn't (on 10.4.2 at least).



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: TvE on Aug 26, '05 03:20:05PM

I believe that the payload of 48 bytes + the Forward Error Correction of 5 bytes equals 53 bytes and 1492/53 = 28,1... and since 28*53=1484 would'nt THAT be the optimal MTU???

http://cell-relay.indiana.edu/cell-relay/FAQ/ATM-FAQ/FAQcells.html



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: cahaddras on Aug 26, '05 06:52:27PM

There are further protocol layers to take into account. In addition to the 1454 for the IP packet, the complete payload before splitting into ATM cells contains 2 for the PPP header, 6 for the PPPoE header, 14 for ethernet, 2 for VCMux, and an 8 byte AAL5 trailer. PPPoE is not very efficient!



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: sighup9 on Aug 27, '05 10:01:01PM

In practice 1492 works quite well (at least it did for me with Verizon DSL - not sure what they use on the head end).

If you want to find the precise threshold for your provider, try http://www.dslreports.com/tweaks



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: cahaddras on Aug 28, '05 07:42:39AM

With ADSL it is not always a matter of finding the highest MTU that works. All packets are transferred as multiples of 48 bytes over the link to the exchange, padding if necessary. The padding wastes throughput, so the trick is to set the MTU at the highest value that results in an exact 48 byte multiple, allowing for the protocol overhead. With a 34 byte PPPoE protocol overhead, 1454 MTU gives a 1488 byte packet which is exactly 31 * 48. 1492 MTU gives a 1526 byte packet, which is 32*48 including 10 bytes padding. If you do the math on an 8Mb connection, that gives a real data throughput of 856kByte/sec for 1492 MTU, and 875kBytes/sec for 1454 MTU.

Note that this only applies if the ADSL link speed itself is limiting. This is always the case for 8Mb, but for anything less than 8Mb some ISPs aim to set a higher link speed than needed and then cap the data throughput. In this situation the wasted pad bytes are just soaked up by the link speed headroom and make no difference on the data throughput. On the other hand if your distance from the exchange is forcing a lower link speed then tuning the MTU in this way will help get the best out of the reduced throughput.



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: Gort on Sep 10, '05 01:31:32PM

I'm not sure I follow the math here. Each 1492 packet will be 32 48-byte chunks, for a total 1536 bytes, of which 34 are overhead, 10 padding. Each 1454 packet will be 31 chunks, for a total of 1488 bytes, of which 34 are overhead. So every 47616 bytes sent will be 31 of the 1492 packets or 32 of the 1454 packets, and

31 * 1492 = 46252
32 * 1454 = 46528

which is a smaller difference than the 875:856 suggested in the article.

(I'm not qualified to comment on the substance; but when I tried to work through the arithmetic, I ended up off your numbers).



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: hj45lp on Sep 03, '05 03:43:24AM

Hi,

I'm wondering whether this cannot be set using the facilities of the pppd daemon instead of editing critical system files. This has been discussed in the comments to this hint. Basically you can specify the MTU in the file /etc/ppp/ip-up using ifconfig. Note the manual page of pppd for further reference (man pppd).

Thomas



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: cahaddras on Sep 03, '05 09:08:54AM

Unfortunately the ip-up script does not appear to be executed, in 10.4.2 at least. Also changing the mtu on the interface in this way is only setting the mtu for outgoing packets. A better UNIX solution is to add mtu and mru options to /etc/ppp/options file as this then negotiates a bidirectional mtu for the ppp link, but unfortunately this has no effect in 10.4.2 either.



[ Reply to This | # ]
Optimising MTU setting in PPPoE ADSL Connections
Authored by: Mecki78 on Jan 14, '10 08:19:15AM

The values are only correct if VCMux is used. If LLC+SNAP is being used (default in many European countries) then 1492 is actually the PERFECT MTU. See this image:

http://f.imagehost.org/0539/PPPoE_DSL_Stack.png



[ Reply to This | # ]