Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
3  
So many bad answers on this question. You all remind me, in a way, of youtube.com/watch?v=SXmv8quf_xM –  Tom O'Connor Jan 7 '12 at 10:34
add comment

6 Answers 6

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

share|improve this answer
    
It's not farther and farther away. –  PHP Feb 5 '10 at 9:58
    
I don't understand what you mean. Each IP address listed on the traceroute is the address of the next router in line between you and google. In the "logical" network topology these get farther away as you progress down the list. Also, for the most part, they get physically farther away from your geographical location. Although this is not always true as sometimes routes seem to jump around the map "unnecessarily". But my point is that physical distance and multiple hops increases the ping time. –  einstiien Feb 5 '10 at 10:31
    
Try pinging each node in the route. You should come up with the same total (roughly). –  Chris Nava Feb 5 '10 at 16:50
1  
Maybe PHP is on the wrong stackoverflow site, and means that farther refers to physical distance whereas further is more appropriate for network distance? english.stackexchange.com –  dunxd Jan 6 '12 at 16:41
add comment

You can see the ping like a drive from New York to San Francisco. It takes, lets say 200 hours (im from switzerland and not familiar with the distances in the US)

But the Driver has to come back to New York to tell you that he was in San Francisco. You take a look to the watch and now you calculate that he took 400hours for the distance. Now that is what Ping does. What Traceroute does is: Tell your Driver he should drive from New York to San Franciso and every time he comes on a crossroad he should come back and tell you the name of it. So he is on his way and the first few crossroads are in New York. So he is pretty fast with driving back to you and telling you the name of the crossroad. But when he gets further afar, he will take longer to return to you. and so on...

So if you count all the driving hours he was on his way he whould take much longer reporting all the crossroads than if he just had to drive to San Francisco. Hope this clears some things up for you...

share|improve this answer
    
A better analogy would be that you send out 30 drivers, telling each of them to head towards New York, but each of them must turn around and come back at the first crossroads, the second crossroads, the third crossroads, and so on, all the way up to thirty crossroads (hoping that there are less than 30 between SF and NY). –  Jed Daniels Feb 7 '13 at 4:14
add comment

In fact it's basically due to the fact that PING sent an ICMP request over the network to the DNS and other Network's appliance.

However, Traceroute send a lot of paquets with a TTL really short.

For exemple when you try to join www.google.com from your seat, traceroute sent a paquet to www.google.com with a TTL set to 1, and wait an answer from the first encounter network's appliance.

Then, Traceroute display the IP of the first network's appliance on you screen, and after it will make the same thing but this time with a TTL set to 2 etc.

At the end, Traceroute has waited for about half more time because, at each send, it's waiting for an answer of an network's appliance.

share|improve this answer
add comment

Traceroute always tell you the average to destination, not an accumulation of times, that is, in your case, it's 34ms with ping and traceroute.

If traceroute were to do what you suggest, its output would be quite unreadable.

If you're only interested in the response time of the destination, ping is quite enough, traceroute is for when you need to debug something on the route to the destination. Moreover, all the hops between you and the destination are routers, and most of the time, routers have a priority on what to do, that is, first route packets, and then answer to ping or traceroute (that is, the first case, answering an icmp echo reply, and in the second case, an icmp time exceeded) and do often answer more slowly (when they answer at all)

share|improve this answer
add comment

Because tracert use UDP packets, like ping use ICMP pakets. Under Linux, whe have the traceroute -I option to do ICMP traceroute.

In your test the time to connect to google is the same in traceroute and ping : 34ms. All the routers in the middle have their own time to answer but doesn't impact the final transfert time.

http://en.wikipedia.org/wiki/Traceroute explain all on Traceroute

share|improve this answer
3  
Actually, on Windows, tracert uses ICMP by default, unlike the Linux traceroute. –  phoebus Feb 5 '10 at 9:06
    
tracert uses ICMP period. ICMP is IP protocol 1, UDP is 17. –  dbasnett Apr 24 '10 at 12:53
    
@dbasnett Originally, traceroute sent outgoing packets as UDP, and the return packets are of course ICMP TTL exceeded messages. Windows and now other traceroute programs use ICMP echo request packets for the outgoing. Typically when people refer to UDP traceroute or ICMP traceroute it is these outgoing packets that they are referring to, since BOTH mechanisms rely on ICMP TTL exceeded messages coming back to the sender from hops along the route. –  Jed Daniels Feb 7 '13 at 4:08
add comment

You can boost your traceroute by disabling reverse dns lookup, which often fail: tracert -d www.google.com

share|improve this answer
    
This does not make the round trip times any faster. It does however make it faster to return results on your screen, since it doesn't do the DNS lookups. –  Jed Daniels Feb 7 '13 at 15:18
add comment

Your Answer

 
discard

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