Measuring latency with the ping utility

Beyond its most common use to determine connectivity, the ping utility can serve as a quick and dirty tool to measure latency - how long it takes one packet to get from X to Y. Latency information is reported directly by ping itself. For each ping reply received, a round trip time is reported. It is measured by the local clock in the pinging computer, from when the request left to when the reply arrived. There is some variation. In the screenshot below, the time it took to hear back from the same destination ranged between 3.01 milliseconds and 4.46 milliseconds. The "-c 10" option tells ping to issue a count of 10 requests. Afterward, in the last line of output, a summary of the times is reported. "rtt" stands for round trip time. The average rtt for the 10 attempts is shown as 3.951 milliseconds. Other options to the command are -i 0.2 telling ping to issue its requests at intervals of 0.2 seconds. Thus, 10 pings should take about 2 seconds. -w 3 means give up after 3 seconds if no replies show up.

Ping times correlate very roughly with distance between source and destination machines. A machine can ping itself very fast. Pinging another machine on the local network is also fast but takes longer, as you would expect. Pinging machines outside the local network takes notably longer. And ping time increases with geographic distance.

Based on the speed of light, which is about 1 foot per nanosecond (billionth of a second), and which limits signal speed, when you ping to great distance you can calculate theoretical minimum time. A shorter time would be impossible. For example covering the 5500 miles from L.A. to Tokyo would take light about 30 milliseconds. A round-trip would take it 60 milliseconds. If we assume ping can't outpace light, you should worry if ping reports a sub-60 rtt to Tokyo. Compare 60  with the 3-4 achieved above. We got 3 milliseconds above, but will never get that to Tokyo. The above ping only went across town, not across the ocean. Short trips take less time and conversely.

The exercise to perform:

Use ssh to log in to unexgate.dmorgan.us with user account "cs70" and password "Wireshark-CS70". You will find yourself on a desktop PC with hostname "vzserver" and IP address 192.168.1.150. vzserver is in Los Angeles. Have it ping itself:

ping  -c 10  -i  0.2  -w 3  192.168.1.150

and note the average round trip time. Ping similarly the following, recording the round trip time averages:

192.168.1.151 - a virtual machine running within vzserver
192.168.1.1 - another PC on the local network, feet away from vzserver
149.142.235.1 - another computer in the adjacent network, probably in the same building
169.232.49.178 - a computer farther afield but within the same organization
137.164.24.18 - a computer still farther afield but still within the same organization
4.2.2.2 - a Verizon nameserver in Los Angeles
72.21.81.63 - a server in Santa Monica utilized in internet speed tests by www. speedtest.net
8.8.8.8 - a Google nameserver in Northern California
140.114.79.231 - a computer in Taiwan
200.19.159.34 - a computer in Brazil

Do you see a correlation between distance and latency?

There is a script that performs this same test on a long list of about 300 target computers distributed around the world. It's on vzserver in cs70 user account's home directory. Run that script:

~/ping-to-urls

The URLs for these computers are printed, along with the average round trip time to ping them. The URLs reveal something about their probable location, either by name or country code. For example "ricepl-1.cs.rice.edu" and "amigos13.distlab.diku.dk" are probably in Texas and Denmark, respectively, because Rice University is in Houston, Texas, and .dk is the country code for Denmark. The script takes a while to finish. When done it leaves a sorted report on screen of the fastest 10 and slowest 10. Note that the fast ones are almost all domestic while the slow ones are generally overseas.