I am using the ping utility to troubleshoot what seems to be a slow Internet connection on my home network, but I'm finding the results unusual and difficult to interpret.

I have a Linksys wireless router, and have tried the following simultaneous tests: pinging the the router from my computer, pinging google.com from the router, and pinging google.com from my computer, via the router. Pinging the router from the computer, and pinging Google from the router both work as expected, with minimal packet loss, and low round-trip time ( min/avg/max = 1.601/3.465/9.926, and 20/20/70 respectively).

However, pinging Google from my computer, via the router, reports something that seems very strange to me. It reports a low RTT, and minimal packet loss, but the interval of each ping request, which should be the default 1s, is more like 10s. What this looks like is about a 10s delay between each time ping prints some output. But the resulting RTT is low, e.g.:

64 bytes from icmp_seq=31 ttl=52 time=29.2 ms

When I run this side-by-side with the other tests, the other tests will have sent about 100 requests at the time that this test will have sent 10. This seems to contradict the low RTT reported, so I'm not sure how to make sense of this.

I'd appreciate any insight anyone can offer.

  • i am expecting the same issue... just set up a new gentoo box and wanted to test my network config. ping to google took extremly long. on my windows machine everything ran fine (normal numbers). then i fired up links-browser on my gentoo box if my network is bad, but it loaded pages like normal... – Baarn Apr 24 '11 at 12:58
  • 1
    Can you paste in (or use pastebin.com or gist.github.com) the full ping output from all three simultaneous ping tests, including the summary statement after you Ctrl-C? I'm having a hard time believing you're really getting the low packet loss and RTT you think you're getting. – Spiff May 23 '11 at 7:00
  • Time the delay. It is very useful to know if it's always greater than but close to a specific number. – Brian May 23 '11 at 23:48

It seems that ping does a name resolution before each ICMP request is sent.

Maybe it is implemented that way, so that a long-running ping will continue to ping the correct host, even when the host<->IP mapping changes during runtime.

If there is a delay in name resolution (for example, because the RR has a very low TTL and your caching DNS server does not enforce a minimum TTL), then you will likely see long delays between each ICMP request, but individual responses having a low TTL.

Long story short, as suggested elsewhere, try ping -n.


Run ping with the -n option, so that it does not do reverse name resolution. It is probably your router's dns software, and ping is waiting for the result of the dns lookup and not the icmp reply.

If -n helps, you have two options:

  • fix your router
  • switch to some public dns provider on your PC (like google public dns)

I also had the problem with 'slugish' ping results after installing dd-wrt as the gw router. I also noticed 'slugish' ping from linux boxes, but no problems from windows boxes. I tried to run with -n and this improved the ping!

Question is, what is root cause, how to fix it so that the lookup goes faster like before?


Is there some QoS feature on your router (especially if it's flashed to Tomato or DD-WRT) limiting or de-prioritizing ICMP traffic? It could be the router is rate-limiting pings. So it could be the router is allowing LAN hosts to issue only 1 ping per 10 seconds, but when that ping is allowed through it works fine, so that could account for the low RTT but high delays.

  • I came across a similar case. If it was a QoS problem of some sort, it would show up in ping as high rtt or dropped packets, but neither is the case here. It's really a DNS issue – lemonsqueeze Jan 3 '13 at 8:04

Trying running ping with the -n option so it doesn't try to do name lookups. If it keeps trying to look up the DNS hostname of the machine you're pinging (or some router that's sending back ICMP Unreachable messages), then that could be hindering ping enough to keep it from getting out more than one packet every few seconds.


The QoS suggestion is a good one, but I would expect the computer to report the other nine pings as lost if QoS discarded them or with increasing RTT values if the router was holding them for QoS and sending them in batches.

My suggestion would be to check whether ping might be aliased to ping -i 10, causing it to only send one packet per 10 seconds. Alternately, you could try issuing the command ping -i 1 <host> to force it to send pings at one-second intervals.

Note that this is assuming you mean that a single ping result (with low RTT) is being printed every ten seconds. If you're getting ten results each ten seconds, but they're all coming at once rather than an evenly-distributed one per second, then that sounds like there's some kind of output buffering taking place in your display.


Did you ping google.com or a IP address? You may not hit the same server by pinging google.com they have thousands of servers and based on where you live you may be directed to one or many of them due to server load at any given time.


I know it is an old question, but we have faced the issue of long pauses between pings on our old machines and the issue was a bug in Avahi Daemon when a domain doesn't have a PTR record. Once we disabled this daemon (sudo service avahi-daemon stop), the pauses were gone.

Here is a relevant article: http://www.unchartedbackwaters.co.uk/pyblosxom/debian_ubuntu_dns_resolution_delays

Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940

Debian bugtracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414569

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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