On Tuesday 20 Sep 2016 19:38:02 David Haller wrote: > Hello, > > On Tue, 20 Sep 2016, Grant wrote: > >>>Strangely, I'm able to ping with that command even with a very high -s > >>>value: > >>> > >>>$ ping -c 4 -M dont -s 9999 www.dslreports.com > >>>PING www.dslreports.com (126.96.36.199) 9999(10027) bytes of data. > >>>10007 bytes from www.dslreports.com (188.8.131.52): icmp_seq=1 ttl=54 > >>>time=331 ms > >>>10007 bytes from www.dslreports.com (184.108.40.206): icmp_seq=2 ttl=54 > >>>time=329 ms > >>>10007 bytes from www.dslreports.com (220.127.116.11): icmp_seq=3 ttl=54 > >>>time=329 ms > >>>10007 bytes from www.dslreports.com (18.104.22.168): icmp_seq=4 ttl=54 > >>>time=329 ms > >>> > >>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms > >>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms > >>> > >> Look again! You're just looking at the _PING_ packets, not the ICMP/IP > >> packets actually going over the interface! You'll need to run > >> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but > >> there's two IP packets actually going over the interface, due to the > >> ping-packet being too large and being fragmented. > >> > >> Start the tcpdump in another (x)term before running the "ping" ... > >> > >> If you use '-M do', you should get the > >> > >> "Frag needed and DF set (mtu = NNNN)" > > > >I switched to '-M do' and found that 1464 is the highest size I can > >ping without the "Frag needed" error. This means I should add 28 to > >that > > The overhead of 28 bytes is just specific to ping. > > It means that your upstream has a MTU of 1492 bytes. And it depends on > your local needs if setting this MTU network-wide is the best course. > I think I and others wrote enough for you to decide. > > >and set my MTU to 1492 across the network? > > Probably yes. I'd even say: unless you know otherwise for your local > needs. It's a very small "pay" (-0.5% max throughput) locally for a > potentially much bigger gain towards the 'net side, esp. when > factoring in latency ... And BTW: changing the MTU is easy, why not > start with one system? Even temporarily just using ifconfig/ip > commandline (don't forget to set the default-route if you "down" the > connection: 'route add default gw $GW_IP' ) and running some > tests/benchmarks. > > HTH, > -dnh
Leaving your MTU at the default ethernet size of 1500 on your PC/server should not cause a problem for most day to day operations, because modern end-point OS and network devices use Path MTU Detection. Problems will arise when you come across a misconfigured router/firewall/server (internet black hole) which drops ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its MTU to make sure you can receive packets of the appropriate size. I have no idea if PMTUD is in any way relevant to the TCP queue spikes you have observed, but they are caused by TCP buffers overflowing. Some detective work at the time these overflows take place would show what the server is doing at the time. -- Regards, Mick
Description: This is a digitally signed message part.