Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


57 posts

Master Geek
+1 received by user: 1


Topic # 66978 26-Aug-2010 12:49
Send private message

As I always feel the need to improve things that are working perfectly fine, I started to tinker with my MTU settings. According to <a href="http://forums.speedguide.net/showpost.php?p=1857596&postcount=6">this post</a> the best MTU for PPPoA is 1478 bytes.

It appeared indeed slightly faster, but not sure if that's really measurable given all the other factors. Moreover, if I set my MTU to 1478, would that really limit what my ISP sends as well? It might have an effect on upload, but on download?

Any insights appreciated. 

Create new topic
1984 posts

Uber Geek
+1 received by user: 133

Trusted

  Reply # 373306 26-Aug-2010 19:11
Send private message

MTU is "maximum transmission unit" so of course has no effect on receiving. Normally 1492 is best for internet because it allows for internet overheads without reducing the packet size too much. On a gigabit LAN your local machines normally a much bigger MTU because small MTU slows down the speed.




Qualified in business, certified in fibre, stuck in copper, have to keep going  ^_^

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 373832 28-Aug-2010 07:22
Send private message

Typically bigger is better. It will depend on your circuit type and size, the encapsulation used, and the packet sizes you're expecting to send and receive.

For consumer broadband I'd strongly recommend leaving at the default (usually 1500 or very close to it) as 1500 is the de-facto Internet standard. If you are dealing with consistently very small packets then lowering it MAY make sense if serialisation delay is an issue (unlikely for 99% of apps), but that can cause unintended consequences when far-end hosts try to send packet-sizes larger than your router is willing to receive and is highly dependent on path MTU detection (PMTU-D) working which is rarely flawless. Note that MTU will often result in MRU negotiation so you end up with consistent MTU on both sides of the circuit. If you lower your MTU and negotiation/PMTU-D fail the first symptom typically seen is that of SSL websites failing...



57 posts

Master Geek
+1 received by user: 1


  Reply # 373838 28-Aug-2010 08:18
Send private message

PenultimateHop: Typically bigger is better. It will depend on your circuit type and size, the encapsulation used, and the packet sizes you're expecting to send and receive.


Not really. See the above calculation that does it optimally for pppoa. But I was just wondering if there was a good way to measure it.

Infrastructure Geek
4057 posts

Uber Geek
+1 received by user: 195

Trusted
Microsoft NZ
Subscriber

  Reply # 373851 28-Aug-2010 09:14
Send private message

no point in increasing your MTU if any hops in between you and your destination have a smaller MTU - you'll just get fragmentation which could result in missing fragments and retransmissions.

to find the "best" MTU, you would have to send packets to and measure responses from every host you want to optimize. thats going to be somewhat difficult to achieve over the internet :P you may be able to optimize for a single host or small handful if you constantly do large downloads from them.

i did some messing around once - on a fibre connection though. I couldnt find a good balance for MSS/MTU that worked well for both local (NZ) hosts and overseas (US/EU etc) but i could definately see differences. one difference i could see when optimizing for far away hosts was that the speed of a download on a single thread could be increased. e.g. from 250KB/s to 500KB/s. the differences on local hosts was much less - more like 800KB/s going to 850KB/sec. If i used the unoptimized settings, I could still get the higher throughput from *either* location when using a multi-threaded download utility...




Technical Evangelist
Microsoft NZ
about.me/nzregs
Twitter: @nzregs


637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 373861 28-Aug-2010 09:51
Send private message

berend:
PenultimateHop: Typically bigger is better. It will depend on your circuit type and size, the encapsulation used, and the packet sizes you're expecting to send and receive.


Not really. See the above calculation that does it optimally for pppoa. But I was just wondering if there was a good way to measure it.

Yes, really. Bigger MTU will typically mean less packets on the wire; and will mean less forwarding lookup overhead -- that's why jumbo frames are used regularly on high-speed links.

There's more to it than the calculations in your quoted link.  For instance, RFC2364 allows for payload padding to ensure that your CPCS headers will fit in the last 48-byte cell of the overall PPPoA payload.  This also only becomes relevant when you are sending large packets (e.g. bulk transfer -- ICMP ping; Quake; VoIP; etc won't do this) that require multiple cells or IP packets onto the wire -- bearing in mind that the so-called optimisation is based on *TCP* overheads of 20-bytes, which may be higher depending on whether any options are used, or may be lower if e.g. UDP (8-byte) is used.  With lower payloads, serialisation delay is the bigger issue. 

Line efficiency is somewhat less of an issue (do you really care about 87.5% "efficient" vs. 86%? can you measure it?) , but on any ATM encapsulated line you will be looking at 8-22% overhead depending on your payload size. 

Noting that TNZ uses PPPoA VCMUX but last I checked should also support LLCSNAP PPPoA as well, I do not think that a 1478 byte MTU is going to make a significant performance difference over 1500 bytes, but will add additional complexity to your life in ensuring that end-to-end connectivity works.   Your end-game difference is 31 cps vs 32 cps.  If using UDP, the story is different.  If using GRE, IPSEC, etc, the story is different.

-PH.
Designs broadband networks for a living.

Edit: typo

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 373863 28-Aug-2010 09:53
Send private message

Regs: no point in increasing your MTU if any hops in between you and your destination have a smaller MTU - you'll just get fragmentation which could result in missing fragments and retransmissions.

to find the "best" MTU, you would have to send packets to and measure responses from every host you want to optimize. thats going to be somewhat difficult to achieve over the internet :P you may be able to optimize for a single host or small handful if you constantly do large downloads from them.

i did some messing around once - on a fibre connection though. I couldnt find a good balance for MSS/MTU that worked well for both local (NZ) hosts and overseas (US/EU etc) but i could definately see differences. one difference i could see when optimizing for far away hosts was that the speed of a download on a single thread could be increased. e.g. from 250KB/s to 500KB/s. the differences on local hosts was much less - more like 800KB/s going to 850KB/sec. If i used the unoptimized settings, I could still get the higher throughput from *either* location when using a multi-threaded download utility...

Optimising your TCP Receive Windows (RWIN) is going to have much more of an impact for any of these rather than MTU.

MTU mismatches on the Internet (caused by upsizing or downsizing the end-nodes) cause significant heartache and pain when PMTUD fails to work.

836 posts

Ultimate Geek

Trusted

  Reply # 373869 28-Aug-2010 10:02
Send private message

Serialisation is only likely to be a problem when the traffic is multiplexed with larger packets from another traffic flow and either traffic flow is delay or PDV sensitive. The vast majority of consumer BB traffic in the uplink is not going to have issues due to uplink serialisation issues and MTU.

As PH says, tweaks to TCP windowing are likely to have much more of an effect then minor MTU changes in this instance.

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 373875 28-Aug-2010 10:09
Send private message

Fraktul: Serialisation is only likely to be a problem when the traffic is multiplexed with larger packets from another traffic flow and either traffic flow is delay or PDV sensitive. The vast majority of consumer BB traffic in the uplink is not going to have issues due to uplink serialisation issues and MTU.

I agree for the most part, but if you consider the scenario of a VoIP call (say ~200bytes per packet) contending for uplink bandwidth with a bulk-upload (~1500 bytes per packet), then you will see serialisation issues if your router doesn't support PPD/EPD or packet pre-emption -- and that's assuming it has a decent scheduler.  This is one of the big drivers for moving to PTM in VDSL, as it does support packet pre-emption.

Otherwise, yeah - don't screw with your MTU unless you absolutely understand the consequences of doing so.

836 posts

Ultimate Geek

Trusted

  Reply # 373878 28-Aug-2010 10:27
Send private message

Yup for sure, hence my cavet excepting traffic flows with delay of PDV sensitivity - that's what those dynamic jitter buffers are for anyhow!

I have been working on geo sat systems since I have come over to the UK, MF-TDMA inroutes with non static slot assignments over a 360ms frame - now that's some serialisation and jitter for you!

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 373889 28-Aug-2010 11:04
Send private message

Fraktul: Yup for sure, hence my cavet excepting traffic flows with delay of PDV sensitivity - that's what those dynamic jitter buffers are for anyhow!

I have been working on geo sat systems since I have come over to the UK, MF-TDMA inroutes with non static slot assignments over a 360ms frame - now that's some serialisation and jitter for you!

That makes my head hurt :(

Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.