Ping at the speed of light

A few weeks ago, someone mentioned to me that when you send a packet over the internet, it travels at a significant fraction (~80%) of the speed of light, just based on the time it takes to get a response and the physical distance travelled. This was surprising to me, but it was believable enough for me to spend some time investigating it.

We can get a pretty good estimate of the speed that the packet is traveling at by pinging a server and doing some math:

$ ping wesleyac.com
PING wesleyac.com (192.64.119.124) 56(84) bytes of data.
64 bytes from 192.64.119.124 (192.64.119.124): icmp_seq=1 ttl=50 time=80.1 ms

This server is located in LA, and I'm in NYC, putting the distance at 3965 km (7930 km for a round trip). That gives us a speed of just over 99000 km/second. We can find the speed of light in fiber optic cable¹ by dividing the speed of light in a vacuum (299,792,458 m/s) by the refractive index of fiber optic cable (usually ~1.468)², getting ~204,218,296 m/s. Thus when I ping my server, I'd estimate that on average the packet is travelling at around 48% of the speed of light in fiber optic cable. This is quite impressive (It's about 22 million times faster than the Pony Express, for example³), but it's not the ~80% figure that I'd heard, so I decided to investigate further.

One thing that might be happening is that my packet isn't actually going directly from NYC to LA - I can use traceroute to find the exact path that it's taking:

$ traceroute wesleyac.com
traceroute to wesleyac.com (192.64.119.124), 30 hops max, 60 byte packets
 1  gateway.net.recurse.com (10.0.0.1)  2.943 ms  2.850 ms  2.866 ms
 2  207.251.103.45 (207.251.103.45)  37.430 ms  37.652 ms  37.576 ms
 3  te0-7-0-18.ccr21.jfk04.atlas.cogentco.com (38.104.73.241)  3.932 ms  3.794 ms  3.790 ms
 4  telia.jfk04.atlas.cogentco.com (154.54.11.110)  4.245 ms  4.241 ms  4.158 ms
 5  nyk-bb3-link.telia.net (62.115.140.210)  3.719 ms nyk-bb3-link.telia.net (62.115.140.106)  3.767 ms nyk-bb3-link.telia.net (62.115.123.6)  3.787 ms
 6  las-b24-link.telia.net (62.115.116.96)  85.758 ms las-b24-link.telia.net (62.115.138.101)  82.792 ms las-b24-link.telia.net (62.115.116.96)  83.911 ms
 7  incapsula-ic-306837-las-b3.c.telia.net (62.115.45.234)  80.535 ms  80.515 ms  80.482 ms
 8  172.20.0.198 (172.20.0.198)  80.534 ms  81.517 ms  80.691 ms
 9  199.193.7.150 (199.193.7.150)  80.616 ms  81.551 ms  81.491 ms
10  199.193.7.162 (199.193.7.162)  82.897 ms  82.538 ms  81.855 ms
11  192.64.119.124 (192.64.119.124)  80.515 ms  81.523 ms  81.671 ms

Doing this, I can see that while the majority of the hops are fairly short, most of the time is taken up between hops 5 and 6, which are when it actually goes from the east coast to the west coast. For a while, I toyed with the idea of geolocating each hop, and finding the total distance travelled that way. However, there's a much easier way to find the latency between two hops - AT&T has a webpage that shows the latency between almost any of it's nodes. The LA to NY latency as of this writing is 63 ms, which works out to ~62% of the speed of light in fiber.

We can use a simple script to calculate the latencies for all of these:

Interestingly, the fastest one of these is Denver to Chicago, which goes at 154.5 km/ms, or ~76% the speed of light in fiber! This is approximately the same speed as SF to Hong Kong, which is quite surprising - I would expect SF to Hong Kong to be much faster than Denver to Chicago, since a larger percentage of the time would be spent travelling over fiber.

Overall, the thing that surprised me the most about this was how consistent the timing was:

I now have a much better intuition for how fast packets travel, and I hope that this was enlightening for others as well!

Thanks to Christian Ternus, Dan Luu, and Laura Lindzey for comments/feedback/discussion.