Kitz Forum
Internet => General Internet => Topic started by: Weaver on March 04, 2017, 03:22:20 AM
-
What MTU / MRU are you using? Out of interest. Ask if you aren't familiar with these terms. See
https://en.m.wikipedia.org/wiki/Maximum_transmission_unit (https://en.m.wikipedia.org/wiki/Maximum_transmission_unit)
and interesting reading at
http://www.aa.net.uk/kb-broadband-mtu.html (http://www.aa.net.uk/kb-broadband-mtu.html)
See earlier
http://forum.kitz.co.uk/index.php/topic,16728.msg308402.html#msg308402
for valuable contributions from various.
Any problems or oddities ever seen associated with different choices? Mentioning what DSL or FTTP or whatever protocols and kind of kit too, would be helpful.
Another thing, I would be interested in opinions about whether the paragraph on problem cases on the internet discussed in that aa.net.uk webpage (linked to earlier) is still relevant, because iirc that webpage has been around for a good while, and may or may not be out-of-date in this respect, as networks' sysadmins may have improved their act in recent years.
[Moderator edited to merge two consecutive postings into one.]
-
I'm using the default MTU of 1492
-
All systems connected to my LAN have the MTU set as "auto".
The CPE, a ZyXEL VMG1312-B10D, my gateway to the Internet, has the MTU set to 1500.
-
My router (TP-Link Archer C2) is set at its maximum value, which is 1492. The various Linux computers connected to it are set at their default value of 1500, but this is effectively dynamic because of path MTU discovery.
This is with FTTC.
-
@roseway - is this without a separate DSL modem, it's a combined modem-router? - haven't looked this model up. Just wondering why 1492 is the maximum?
-
I have a separate modem, a VMG8324-B10A. It appears that I lied - I was thinking of my previous router. The Archer C2 has a default of 1480 for PPPoE, and it says "Do not change unless necessary".
-
Btw, can the VMG8324-B10A do RFC 4638 and cope with ethernet 1508-byte payload ‘baby jumbo’ frames?
Since you aren't using ATM but rather PTM (?) over DSL, if my understanding is correct, then there’s no loss of efficiency from using 1500-byte long IP packets compared with 1492, so if you could manage it then there would be a tiny speed increase due to the improved IP + TCP header overhead ratio.
-
I'm afraid I have no idea what the situation is with baby jumbo frames. As for tweaking the MTU on the router, I'm fortunate enough to have a good fast FTTC connection, and tweaking for tiny speed increases comes under the heading of "Life's too short". :)
-
Life's too short indeed, agreed, you'd never notice the tiny difference as you are not using ATM.
I'm wasting 3% speed by using 1500 byte IP MRU / MTU with PPPoEoA (ADSL2) with my Dlink modems, compared to the optimum of 1492 IPPDUs because that plus other protocols’ overhead fits exactly into an integer number of ATM cells. If 1492 turns out to causes no known problems out on the internet with stupid networks and servers, then perhaps I should go over to 1492.
It would be nice to get rid of ATM some day and just lose all the crazy overhead of >(48+5)/48 + plus the AAL5 CPCS trailer + cell-padding, which is >10% speed just gone down the toilet. In fact, people need to remember that about eg FTTC or anything non-ATM-based, that at the exact same DSL sync rate you just get an extra min 10% speed for free with FTTC compared with eg ADSL2+. Typically 10-13% depending on packet size. (But of course it could be ~100% inefficiency for short packets. For VoIP the ATM overhead is typically huge.) Someone who has the option of FTTC on a really long line, long for VDSL2 anyway, might be trying to compare claimed speed with ADSL2+ based on sync speeds without thinking about the >10-13% wasted.
-
baby jumbo frames is more about making sure you never hit mtu compatibility issues than performance, as the performance gain is nothing of note, but its useful to avoid mtu gotcha's where on a mtu lower than 1500 bytes you can occasionally hit an endpoint that refuses to work.
-
Couldn't agree more with Chrysalis. In my case it's a performance prevention measure. I would love to find a concrete actual problem case of reduced MTU misery on the internet. RevK et al talk about generalities. I appreciate that problem cases do vanish as they sometimes get fixed, so individual instances might not be useful long-term.
-
the traditional mtu discovery mechanism often doesnt work due to the widespread blanket blocking of all icmp packets on many servers. RFC 4821 is a newer method for ipv4 which uses TCP to negotiate MSS so a workaround for the issue but its not enabled by default on linux or freebsd yet as still considered somewhat experimental.
IPV6 also relies on icmp for mtu but there is more compliance from admin's as the message is getting out much more effectively for this one.
-
Billion 8800NL set at 1492 MTU with FTTC cannot change the value but the logs on the Billion always seems to complain about 1500 MTU see below.
Mar 6 14:29:57 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Mar 6 14:29:57 daemon err syslog: pppd:Couldn't increase MRU to 1500
Mar 6 14:29:57 daemon err syslog: pppd:Couldn't increase MRU to 1500
Maximum Transmission Unit (MTU) so (MRU) must be Maximum Receiver Unit :-\
-
Does anyone know of a specific server that always sends out IP packets that are only 1500 bytes long? And what’s more might even have DF set?
-
Unfortunately no, I don't.
I understand the reason for your query and would say that it would be imperative that DF should be set.
I wonder if A&A / Adrian Kennard would have a system that could be configured thus, for testing purposes?
-
@Burakkucat - indeed, seeing as it is something that bugs him.
-
I'm not sure what the purpose of setting up something in such a deliberately bad configuration would be. To check that you can't receive packets from that server because your MTU is too small? For people unable to increase their MTU to 1500 for whatever reason, there would be nothing they could do about it.
-
1492 on FTTC as advised by ISP Uno.