21

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
splattne
  • 28,508
  • 20
  • 98
  • 148

8 Answers8

18

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

einstiien
  • 2,568
  • 18
  • 18
  • It's not `farther and farther away`. –  Feb 05 '10 at 09: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 05 '10 at 10:31
  • Try pinging each node in the route. You should come up with the same total (roughly). – Chris Nava Feb 05 '10 at 16:50
  • 2
    Maybe PHP is on the wrong stackoverflow site, and means that *farther* refers to physical distance whereas *further* is more appropriate for network distance? http://english.stackexchange.com/ – dunxd Jan 06 '12 at 16:41
13

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...

Bona
  • 131
  • 1
  • 2
  • 3
    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 07 '13 at 04:14
  • This is analogy is not correct, see other answers and comment above. – M3RS Mar 02 '20 at 15:39
1

Answer

The reason traceroute is slow is:

  1. it sequentially pings every router along the way until it reaches the host (sequentially, depending on the exact implementation)
  2. it is slowest when there is an *. It means the given router didn't acknowledge the packet and the request timed out instead. The default timeout is 5 seconds and traceroute sends three packets by default, so it takes 15 seconds to figure out that a single router along the way did not respond (* * *).1

Speed up

You can speed up traceroute by sending only two probes per router and reducing the timeout to 3 seconds, for example:

traceroute -q 2 -w 3 google.com

Background

The traceroute command is used to see how packets are getting routed. It works by sending packets with increasing TTL values, starting with 1. So the first router gets the packet, and it decrements the TTL value by one, thus dropping the packet. The router sends back an ICMP Time Exceeded message back to us. And then the next packet gets a TTL of 2, so it makes it past the first router, but when it gets to the second router the TTL is 0 and it returns another ICMP Time Exceeded message. Traceroute works this way because as it sends and drops packets it is build a list of routers that the packets traverse, until it finally gets to its destination and gets an ICMP Echo Reply message.2

Note, the ICMP Time Exceeded is not the same as when the request times out. In the latter case, there is no response at all, while in the former case there is a response.

To speed things up, we don't necessarily wait for a response from a router before pinging the next one:

Modern versions of the traceroute program don’t just send one packet at a time though. To speed things up it sends several packets with varying hop counts at once, so the program doesn’t have to wait for each router to respond before issuing the next packet.3

1 Source: what does "***" mean when traceroute

2 Source: https://linuxjourney.com/lesson/traceroute

3 Source: https://www.perl.com/article/how-does-traceroute-work-/

M3RS
  • 171
  • 5
1

For posterity, since none of the correct answers are very clear...

--

Each time shown in the traceroute is the TOTAL TIME from YOUR MACHINE (or the machine doing the traceroute...) to THAT PARTICULAR NODE.

In other words, the time shown on the 2nd node is not the time taken between nodes 1 and 2, but rather the total time taken between the source, the first node, and the second node all put together.

So on average, the times shown on each node should roughly match the times you would get if you were to ping that particular node "directly" (it's not any more direct than a traceroute in reality...it will usually follow the same path on the internet).

Just keep in mind that there is such a thing as a "lag spike." The most accurate way to find the source of any lag is to run a traceroute on repeat using a batch file (if you're on Windows), and find the nearest (lowest numbered) node that has high numbers at any given time.

--

For the batch file, open notepad and type these 3 lines:

:start
tracert -d www.google.com
goto start

Then save as "Trace.bat" but make sure to change the file type on the save dialogue to "all files" before saving or it will still save as a text file.

When opened, this will constantly run traceroutes (to google). You can stop it by pressing ctrl+c while you have the window selected.

--

You can, of course, change where it is running the traceroute to by changing "www.google.com" to whatever address you feel like.

You can also remove the "-d" option if you wish to see the resolved host names, but this will make the traceroute take longer due to getting said hostnames from a DNS server for each node (this does NOT change the actual results themselves however).

Lastly, if you find a node with high times and just want to run traceroutes to that particular node in case another node before it has issues, you can either change "www.google.com" to that node's ip address or host name, OR you can use the -h option to specify how many nodes out to search, ie...

:start
tracert -d -h 5 www.google.com
goto start
Laike Endaril
  • 111
  • 1
  • 1
    An important note is that a node replies with ICMP, but the primary purpose of a router is to route packets, and creating ICMP responses is far down the list of what it does. A router will route, and it will get around to sending ICMP messages when it gets time. That is why intermediate time could be longer than the full path; the intermediate router could be much busier than the end node. – Ron Maupin Oct 07 '17 at 15:34
  • Yes, the QOS priority of ICMP is usually lower, but often times when you're running a traceroute, it's because a problem already exists (you're having lag spikes or bad ping on a game), and that particular node you mentioned (the busy one) is the bottleneck that you're looking for. – Laike Endaril Oct 07 '17 at 15:37
  • 1
    I don't mean the QoS priority, I mean the device itself creating an ICMP response. The node can actually be too busy routing packets to get around to sending an ICMP message before the original node times it out. A router will route packets before deciding to send an ICMP message. That has nothing to do with QoS. – Ron Maupin Oct 07 '17 at 15:44
  • QoS is a very loosely defined term, and I consider it to include all activities that use the same set of resources, rather than excluding activities that require extra attention (constructing a response packet). Either way though, that doesn't change the fact that the said router is under too heavy a load and is bound to cause issues, so the high times from a traceroute are still a good indicator for where your problems lie...with the possible exception of a large amount of traffic that has a higher priority than your ICMP but a lower priority than your normal traffic. – Laike Endaril Oct 07 '17 at 15:55
0

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)

Dennis Williamson
  • 62,149
  • 16
  • 116
  • 151
mat
  • 1,263
  • 1
  • 11
  • 15
0

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.

Dr I
  • 955
  • 17
  • 33
-1

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

Dom
  • 6,743
  • 1
  • 20
  • 24
  • 3
    Actually, on Windows, `tracert` uses ICMP by default, unlike the Linux `traceroute`. – phoebus Feb 05 '10 at 09: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 07 '13 at 04:08
-1

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

Mathieu Chateau
  • 3,185
  • 16
  • 10
  • 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 07 '13 at 15:18