The Thing About Ping

By Joshua Darrin

The thing about ping is this
It’s handy for computers to say hello
But in order to diagnose problems
We need to understand the traffic flow
I would not, could not, should not call for aid
Until all of my self-help, diagnostic dues have been paid
So stand with me and say it aloud
If I use the almighty ping, I promise I shall.

Verify My Results

Ping results can vary for many reasons so it is always best to first verify that the “issue” lies beyond your local machine and network. Keep in mind that references to your “local network” include potential issues with your Internet provider.

If you’re pinging out to a device on the Internet (a server you own perhaps) and suddenly start seeing longer latency, then quickly follow a few simple steps to verify the results:

1) Ping some of the big providers like and If you see long latency to these guys, then it is more likely that you have a local problem with the machine or network.

2) Run to another machine and try pinging the device you are interested in along with some of the big boys. If this machine shows the same results, then the issue likely points to your local network. If this machine shows different results, then go diagnose the original machine.

If the pings to the big boys all appear normal and pings to your device of interest are still showing a longer latency, then it’s time to move up the chain.

Check the Path

So, now we feel our device may be having network issues because our local network looks good and we can ping the big boys without any real latency. Now it’s time to check the path (we geeks call this a route) that our machine is taking to our device. To do this, we want to trace the route.

1) Windows users should open a command prompt and run the following command: tracert (where is a domain name or an IP address)

2) Mac users should open a terminal window and run the following command: traceroute

This will show you results that look like this:


Tracing route to [] over a maximum of 30 hops:

1 1 ms <1 ms <1 ms MY ROUTER []

2 21 ms 29 ms 28 ms []

3 11 ms 8 ms 10 ms []

4 11 ms 10 ms 11 ms []

5 15 ms 14 ms 14 ms net []

6 13 ms 16 ms 13 ms []

7 54 ms 12 ms 19 ms

8 65 ms 13 ms 14 ms

9 16 ms 14 ms 14 ms

10 15 ms 15 ms 13 ms

11 17 ms 20 ms 16 ms

12 14 ms 14 ms 16 ms []

Trace complete.

This is showing me that my machine is making twelve stops along its path to Google’s DNS servers (we geeks call these hops). These results are expected and normal. We see a tad of latency at steps 7 & 8, but this is nothing to be concerned with since the second and third values are normal.

Look for lines like these to zero in on potential issues. The asterisks mean that the device did not respond and latency times in the triple digits across all three attempts are pretty indicative of a problem.

1 * * * MY ROUTER []

2 121 ms 219 ms 328 ms []

Tracing the route provides deep insight into where traffic is being held up. As a general rule, the first few hops will likely be owned by your Internet provider. The hops in the middle will be the route through other provider’s networks and the final hops will be those owned by the company housing your device.

Calling tech support with this information in hand will speed along the process of resolution. Problems in the middle of the trace will be the hardest because it is tough to know whom to call. Start with your Internet provider as the issue may be in their handoff.

Third-Party Verification

It’s always good to get someone else on a different network (and preferably a different Internet provider) to verify your results. Have a friend run through these steps and provide you with the relevant information. The more you can provide to tech support, the faster problems get resolved.

Leave a Comment