Results 1 to 5 of 5

Thread: Biggest MTU may not always be the best

  1. #1
    Junior Member
    Join Date
    Jul 2011
    Posts
    3

    Biggest MTU may not always be the best

    I came here looking for an MTU discovery test, but the TCP/IP Analyzer is a really cool tool! There is one thing I disagree with: on PPPoE DSL connections, the biggest MTU is not always the best. I just went through great pains to get the MTU set correctly, so I thought I should share it here. I went from 60.1 to 65.0 kByte/s in upload speed, and 765 to 780 in download speed using a MTU of 1448 instead of 1492. This effect is most important for slow connections! Update: This can't be the whole story! The next optimal MTU after 1448 would be 1496. I can't send that big packets, but I'm only losing 4bytes/packet to padding, so take these numbers with a huge grain of salt
    Update 2: MTU can only affect upload speed. Use Linux's "Clamp MSS" hack or set the MTU of your *local* interface to affect download speed.

    PPPoE DSL data is sent over ATM (Asynchronous Transfer Mode), which uses cells of 48 bytes. If a packet size isn't a multiple of 48 bytes it will be *padded*, meaning you are sending/receiving useless padding data. For the best speed, the max. packet size should be a multiple of 48 bytes, but that includes some ATM overhead, which makes things complicated. This page is where I learned this: http://ace-host.stuart.id.au/russell...c-atm/#details . The section called "Overhead and MTU Calculations" will be useful to read even if you are not using tc to do traffic shaping, as it explains how to get the best MTU (skip the first two paragraphs).

    You have to know which PPP protocol you are using, and I couldn't get that info from my modem. There is another way, which also gives you a nice graph: find it experimentally with ping. If you have a linux-based router with python installed, you can use my script, it's at http://www.fa2k.net/misc/PingTest.py . It will ping a host with various ping sizes. A good host to ping is the PPP endpoint, you can do /sbin/ifconfig ppp0, and read off the IP after "P-t-P:". Then call "python PingTest.py <ip-address>" as root. It take about 20 min to run, try to keep the connection quiet while it's running. It will produce a table with IP packet size, which is also the MTU, and the median ping value. You can paste this into your favourite plotting/spreadsheet tool, for example Excel, and make a graph. The best MTU is the first place where it drops off

    Now, you can just put the value you computed or measured into the MTU. It should give some speed-up.

    Hope this helps! Here is the plot for my connection, I found that I had 40 bytes of overhead, so my protocol is PPPoE, LLC/SNAP.
    I can't upload images, oh no! Here it is :
    Last edited by fa2k; 07-24-11 at 05:19 AM. Reason: Correction

  2. #2
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    If a packet size isn't a multiple of 48 bytes it will be *padded*
    If MTU is set at 1448, and MSS is 1408 (less 40 for overheads), neither values are multiple of 48.
    "Contentment is not the fulfillment of what you want, but is the realisation of how much you already have" - anon

  3. #3
    Junior Member
    Join Date
    Jul 2011
    Posts
    3
    Quote Originally Posted by trogers View Post
    If MTU is set at 1448, and MSS is 1408 (less 40 for overheads), neither values are multiple of 48.
    Sorry, I forgot to say: What matters is MTU+ATM and PPPoE overhead. My overhead is 40 bytes per packet, so the total size is 1488.

    I still don't understand why it works, though, since 1492/70.5 ms > 1448/69.5 ms, so the rate is higher at 1492. But I'm sure that it works on my connection.

  4. #4
    Administrator Philip's Avatar
    Join Date
    May 1999
    Location
    Jacksonville, Florida, United States
    Posts
    10,342
    Blog Entries
    6
    Very interesting observation, thanks for sharing. Here are some other thoughts:

    You have to consider the slowest part of the connection, and it is usually near your end, where the encapsulation may not be ATM at all. The backbone transmission is not limited to the same bandwidth, and all those small ATM packets may be transmitted at almost the same time. In other words, theoretically in many cases the ATM overhead should not be the limiting factor (even though ATM encapsulation introduces additional ~9.5% overhead).

  5. #5
    Junior Member
    Join Date
    Jul 2011
    Posts
    3
    Quote Originally Posted by Philip View Post
    Very interesting observation, thanks for sharing. Here are some other thoughts:

    You have to consider the slowest part of the connection, and it is usually near your end, where the encapsulation may not be ATM at all. The backbone transmission is not limited to the same bandwidth, and all those small ATM packets may be transmitted at almost the same time. In other words, theoretically in many cases the ATM overhead should not be the limiting factor (even though ATM encapsulation introduces additional ~9.5% overhead).
    I tried to run the upload test again (it's just wget 10 MB of random data), and I got 66.2 for the small MTU and 65.8 for the large MTU. It seems to be a significant difference (not a measurement error), but it's of course less imressive than the original 60.1 -> 66.2 .

Similar Threads

  1. The biggest pig I've ever seen
    By Brent in forum General Discussion Board
    Replies: 67
    Last Post: 05-29-07, 12:19 PM
  2. Who is the biggest...
    By ghettoside in forum General Discussion Board
    Replies: 23
    Last Post: 04-07-06, 05:37 AM
  3. On SG...who's got the biggest
    By Roody in forum General Discussion Board
    Replies: 23
    Last Post: 05-18-05, 03:30 AM
  4. What's the biggest prize/$ you've ever won?
    By Zilog B in forum General Discussion Board
    Replies: 23
    Last Post: 10-25-03, 09:54 AM
  5. I have the biggest banana...
    By Brk in forum General Discussion Board
    Replies: 44
    Last Post: 09-02-03, 11:36 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •