Költözött: http://www.trinityos.com/PPP/ppp-performance.html#mtu Igazából semmi hasznos, csak az rfc: https://tools.ietf.org/html/rfc1144 , amiben a magyarázat ez:
"(2) Even with a line fast enough to handle packetized typing echo (4800
bps or above), there may be an undesirable interaction between bulk
data and interactive traffic: For reasonable line efficiency the
bulk data packet size needs to be 10 to 20 times the header size.
I.e., the line maximum transmission unit or MTU should be 500 to
1000 bytes for 40 byte TCP/IP headers. Even with type-of-service
queuing to give priority to interactive traffic, a telnet packet has
to wait for any in-progress bulk data packet to finish. Assuming
data transfer in only one direction, that wait averages half the MTU
or 500 ms for a 1024 byte MTU at 9600 bps.
"
Magyarul azért lesz szar a latencyje egy interaktív kapcsolatnak, mert hiába van quos, meg kell várni, míg a már elindított nagy packet átmegy. Namost ez elméletben még ma is igaz, de azért látni kell, hogy ez abból a korból való, amikor egy 33.6k baudos modem a kánaán volt. A gyakorlatban viszont, mondjuk ha ezt a példát nézzük, akkor a 7.2Mbps az 0.9 MB/s vagyis ~950e byte másodpercenként, tehát kb 950 ms-enként, azaz egy 1500 byteos MTU nem egész 2 ms-re tartja fel a forgalmat.
Ráadásul, ha nincs qos, akkor úgyis mindegy. És mivel a userek nagy része HTTPt fog tolni, hacsak valami nem classifyolja le mondjuk a youtubeot, (márpedig nem, mert tudjuk, hogy -- már ha sikerül -- simán csak eldobják).
TL;DR lehet, hogy valaki direkt emiatt vette le, de inkább csak az van, hogy van ott valami a pathban, ami miatt kisebb egy kicsit az mtu (egy plus ipsec, vagy valami ppp keretezés, QinQ, akármi. És mivel ezek a pö... izé, jól képzett szakemberek eldobták valószínűleg a frag neededet, ezért nem ment át.