Why does traceroute take much longer than ping

networkingping

How to explain this?

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

So average time should be :1+7+108+2+1+1+2+1+1+2+2+33+34+34+35+34+34+35+34,which is a lot bigger than ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms

Best Answer

You cant just add together all of those numbers. That is the ping time to each of the hops on the path to google. So natually each leg of the path gets farther and farther away and you see varying ping times. If you look at the last ping time in tracert (34 ms) and the time you received when you issued the ping (34ms) these are the same. The tracert program is no slower than ping.

I would suggest reading up on how a traceroute works:
http://en.wikipedia.org/wiki/Traceroute

Related Solutions

Why mtr is much faster than traceroute

Parallelism is a major reason for variation in the speed of these tools. Another contributing factor is how long they wait for a reply before the hop is considered to not be responding. If reverse DNS is performed, you have to wait for that as well. The plain traceroute command gets much quicker, if you disable reverse DNS.

Another important difference, which I did not see mentioned, is how the two tools render the output. Traceroute produces the output in order top down. Mtr renders output in a different way, where mtr can go back and update output on previous lines.

This means mtr can display output as soon as it is available, because if later replies cause that output to not be accurate, mtr can go back and update it. Since traceroute cannot go back and update output, it has to wait until it has ultimately decided what it will display.

For example if hop number 2 is not responding (which is a symptom I have seen on multiple ISPs), traceroute will display hop number 1 and then wait for a while before it displays hop number 2 and 3. Even though the reply from hop number 3 has arrived it is not being displayed because traceroute is still waiting for the reply from hop number 2. Mtr does not have that restriction and can display the reply from hop number 3 and still go back to display the reply from hop number 2, if it arrives later.

Too much parallelism can cause the output to become inaccurate. In some scenarios there are limits to how many packets you can get replies for. Sending more packets in those cases will not speed up the process, it will however cause more lost packets, as you get the same number of replies with more packets being sent.

One example of this is when a hop on the route does not reply to ARP requests. Usually the first packet will trigger an ARP request, and if more packets arrive before the ARP request times out, only the last of those packets will be buffered and get a reply.

Another difference is in how many hops with no responses will be displayed before the tool stops displaying more hops. I have seen the traceroute command continue for as many hops as requested (30 by default), while the mtr command would stop as soon as it had passed five hops with no responses.

Why is ping not returning local DNS cache result? (Using DNS caching server on an internal network.)

I have found that although the name resolution works with nslookup or the domain name resolution is cached locally, if one does not have a route to the destination ping will fail and never show the IP.

I encountered this issue in another lab without multi-homing. Removing the default gateway would cause ping to fail with "cauld not find host" when pinging a domain name and when pinging the IP, it would show a "transmit failed" error:

C:\Users\pawel>ping google.com
Ping request could not find host google.com. Please check the name and try again

C:\Users\pawel>ping 173.194.123.101

Pinging 173.194.123.101 with 32 bytes of data:
PING: transmit failed. General failure.

Related Topic