Why does traceroute take much longer than ping?

Solution 1:

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

Solution 2:

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

Solution 3:

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