5
0
I've been experiencing some odd behavior. While on a congested wireless network I run
$ ping google.com
I expect one packet to be sent out each second and only some of them to come back with a variety of round trip times, and this is the behavior most of the time. But on this very congested wireless network I see something like this:
PING google.com (74.125.224.228) 56(84) bytes of data.
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=1 ttl=53 time=193 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=2 ttl=53 time=238 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=3 ttl=53 time=96.8 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=4 ttl=53 time=12.9 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=5 ttl=53 time=219 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=9 ttl=53 time=1105 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=8 ttl=53 time=2339 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=17 ttl=53 time=881 ms
64 bytes from lax04s08-in-f4.1e100.net (74.125.224.228): icmp_req=18 ttl=53 time=1200 ms
...
--- google.com ping statistics ---
57 packets transmitted, 41 received, 28% packet loss, time 113307ms
rtt min/avg/max/mdev = 5.773/447.217/2339.271/496.011 ms, pipe 3
The key line is:
57 packets transmitted, 41 received, 28% packet loss, time 113307ms
as you can see the ping ran for about 113 seconds but only sent out 57 packets. I've seen this multiple times:
$ ping google.com
PING google.com (74.125.224.232) 56(84) bytes of data.
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=1 ttl=53 time=6.98 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=2 ttl=53 time=5.71 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=3 ttl=53 time=4.47 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=4 ttl=53 time=5.75 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=5 ttl=53 time=6.94 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=6 ttl=53 time=14.2 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=7 ttl=53 time=6.22 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=8 ttl=53 time=11.8 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=9 ttl=53 time=4.29 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=10 ttl=53 time=5.43 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=11 ttl=53 time=5.02 ms
64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=12 ttl=53 time=4.89 ms
^C64 bytes from lax04s08-in-f8.1e100.net (74.125.224.232): icmp_req=13 ttl=53 time=7.36 ms
--- google.com ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 60262ms
rtt min/avg/max/mdev = 4.299/6.865/14.258/2.838 ms
This one is even weirder because all the RTTs are reasonable, the packets just aren't getting sent out quickly. Can anyone shed light on this? I'm on debian testing (wheezy), and a few more stats:
$ ping -V
ping utility, iputils-sss20101006
Linux 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
But shouldn't the DNS responses be cached? Basically -n makes it faster - but we found out, that on Debian systems, using non -n on a host that does not have a reverse DNS entry does not slow down the process. Maybe it is more a problem with the whole DNS setup on Ubuntu? – Alex – 2013-01-18T08:29:34.080
1@Alex Lookups would be cached if the local machine is running a caching server and DNS is setup to try the loopback address first. I think Ubuntu would be one of the least likely distributions to be running a caching server by default. – Kyle Jones – 2013-08-08T22:55:46.270
Well it took me over a year but I was finally on a network where I was seeing this behavior again and was able to verify that
ping -n
gave the expected behavior. Thanks @KyleJones ! – Matt – 2014-01-17T17:34:26.207