Best MTU

Forums › New Zealand Broadband › Best MTU

berend

62 posts

Master Geek

#66978 26-Aug-2010 12:49

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.

webwat

2036 posts

Uber Geek

Trusted

#373306 26-Aug-2010 19:11

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.

Time to find a new industry!

PenultimateHop

637 posts

Ultimate Geek

Trusted

#373832 28-Aug-2010 07:22

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...

berend

62 posts

Master Geek

#373838 28-Aug-2010 08:18

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.

Regs

4066 posts

Uber Geek

Trusted

Snowflake

#373851 28-Aug-2010 09:14

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...

Sales Engineer
Snowflake
www.snowflake.com

about.me/nzregs
Twitter: @nzregs

PenultimateHop

637 posts

Ultimate Geek

Trusted

#373861 28-Aug-2010 09:51

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

PenultimateHop

637 posts

Ultimate Geek

Trusted

#373863 28-Aug-2010 09:53

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.

Fraktul

836 posts

Ultimate Geek

Trusted

#373869 28-Aug-2010 10:02

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.

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

PenultimateHop

637 posts

Ultimate Geek

Trusted

#373875 28-Aug-2010 10:09

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.

Fraktul

836 posts

Ultimate Geek

Trusted

#373878 28-Aug-2010 10:27

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!

PenultimateHop

637 posts

Ultimate Geek

Trusted

#373889 28-Aug-2010 11:04

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 :(