When I saw “Why The Speed Of Light Can’t Be Measured” I was struck by how similar in nature it was to measuring network latency with ping.
I’m actually doing this right now to debug some problems, but with TCP, which basically boils down to the same: embed a timestamp with your application message, and compare it with a local timestamp when you receive the message.
If you’re using AWS, they expose an NTP server based on GPS and Atomic Clocks which has good enough accuracy to measure millisecond-level timing information.
Not the same thing, but along a similar line of thought: https://www.finnie.org/software/2ping/ — bidirectional ping.
Apologies that I’m typing this on my iPad on the go here and will be a bit vague on details.
One approach I’ve done for simultaneous latency and clock delta measurement involved UDP packets that implemented the bare minimum of the conceptual NTP protocol. There’s four timestamp involved, and the clocks on both ends don’t need to be synchronized:
From the four timestamps, machine 1 can compute, IIRC:
I don’t recall off the top of my head the exact algebraic formula for doing so, unfortunately.
If you label the four send/receive events as t1, t2, t3, t4 in the order they happen, the roundtrip latency is (t2+t4-t1-t3), and the clock delta under the assumption that latency is symmetric is (t2+t3-t1-t4)/2. You can’t reliably measure a rate difference this way (you need multiple round-trips separated in time) and you can’t disentangle asymmetric lag from clock delta. You can only measure a clock delta by making an assumption about latency (e g. that it’s symmetric), and you can only measure two-way latency by making an assumption about the clocks (e.g. that they’re in sync already). It’s a fundamental limitation.
Huh! I’m going to have to dig way back in my notes and refresh! Thanks for the correction! It’s been a while.
Edit: yeah, you’re totally right. Thanks!
Sorry if this sounds like a stupid question. Does the UK have a geo-local version of NIST’s high-accuracy clocks?
Yes, NPL runs ntp1.npl.co.uk / ntp2.npl.co.uk. Wouldn’t be surprised if there were others.
This is really interesting. I’ve thought about the problem in the past and had considered measuring the latency asymmetry almost impossible. The author gets much farther than I thought you could without some special hardware (granted, using a GPS to estimate the error of NTP).
However, I’d love to see a more thorough analysis of the achieved accuracy. From the article I can just see that the difference between the PPS and NTP-synced system time is around 3-4ms. There may be other error sources, but just assuming the measurement accuracy is +-3ms on both ends, the measurement of 15ms RX / 5ms TX could theoretically be 9ms RX / 11ms TX instead. I do believe the results are much more accurate in practice, but I’d love to know just how accurate the clocks are and what the probable range of RX/TX latency asymmetry is.
It is likely impossible to actually measure the one-way latency of a link. There will always be uncertainty. You can lower that a lot, but it will probably not be possible to be certain about the numbers.
Veritasium has a nifty video on the problem, but framed with figuring out the one-way speed of light: https://www.youtube.com/watch?v=pTn6Ewhb27k
I’m not sure what you mean by “actually measure”. The author has done just that, only with unknown accuracy. In a similar manner, you cannot measure a person’s height accurately, but we’re happy with a measurement that’s accurate to the centimeter (or inch).
Since ping tends to be in the >10ms range with >1% jitter, I’d say measuring the directional asymmetry down to <1ms error would already be worthwhile, and at 0.1ms the measurement would be almost as accurate as ping itself. The only difficulty is synchronizing clocks well enough. While that may be impossible to get into the millisecond range with NTP and consumer hardware, getting two clocks under a microsecond apart should be quite doable with an RTOS system built around a GPS receiver. GPS time is theoretically accurate down to 14 nanoseconds.
The point of the video is that you have no idea if the clocks are accurate at either end. You can make assumptions and they will probably work in the real world, and the latency can be so low that it doesn’t really matter, but as long as you can’t know the clocks are actually in sync (and NTP/GPS won’t help you here) you don’t actually know what the latency between point A and point B is. Just what the timestamps claim it to be. The video goes into a better explanation for this issue.
The clocks cannot be in sync, but they only need to be near. I’m no expert, but in my understanding the fact that GPS works down to <10m accuracy is good evidence that the satellite clocks are less than a microsecond apart in the GPS user’s referential frame. I know the physics and the relativistic effects are complicated and I’ll probably never fully understand them. And of course we’ll need assumptions, eg. that the universe exists, our senses are trustworthy, logic is trustworthy, general relativity holds etc.
Now if the speed of light did vary directionally, in my understanding the clocks in GPS satellites would only seem to be almost in sync. They actually could be off by tens of milliseconds! But there would be no way to know, because we cannot measure the speed of light asymmetry.
So one way to look at this is that we have the international atomic time (TAI) and the global positioning system (GPS) that rely on nearly-synchronized clocks around the world. And based on that almost-synchronized time we could measure the timings of things on the opposite sides of the Earth down to microsecond and probably nanosecond accuracy.
The other way to look at this is that we don’t know if the clocks are truly in sync or if it just seems that way. Similarly we can take the Regress argument, concede that we cannot actually know anything, and end up with philosophical skepticism.
If you know that every machine you’re interested in pinging is connected directly to a GPS clock, everything works out fine to within the limits of GPS.
If you assume that the remote machine has a “pretty good” NTP sync, then you can get an equally pretty-good picture of the two-way latency (but you probably have no way to check that assumption).
But if you know nothing in advance about the state of the remote clock, then you gain zero information about the two-way latency using sping.