Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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)
share|improve this question

1 Answer 1

up vote 6 down vote accepted

It looks like you have one of the versions of ping that does a DNS lookup for every received packet. Since a DNS UDP packet has to traverse the same congested network as ping packets, the packet may be dropped. With timeouts and retries it can take significant time for a DNS request to return data. The time consumed waiting for a DNS response delays the sending of the next ping packet because your ping is both single-threaded and doesn't use an asynchronous timer to drive each ping.

If my diagnosis is correct, adding -n to ping should get rid of the delays.

share|improve this answer
    
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 Jan 18 '13 at 8:29
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 Aug 8 '13 at 22:55
    
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 Jan 17 at 17:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.