It’s widely-believed that geographic proximity is the main factor determining the accuracy of NTP. While I’m not necessarily disputing its importance, I wanted to mention some interesting tests I’ve done.
As I mentioned earlier, my (“our,” really — @ co-owns it, and keeps paying the bill without sending me his PayPal address… g) NTP server was incorrectly, and pretty randomly, labeled as being in Brazil, and thus set to serve time to people in Brazil and, more generally, South America. But the server is in Pennsylvania.
Surely, then, with such a long distance, quality must be terrible? I decided to measure it in reverse: I did a “mock sync” to the South American pool from my server in Texas. The command ntpdate -q servername will “sync” to a server (or set of servers) via NTP, but only show you the offset it would have applied, rather than actually adjusting your clock. I ran this on a server that’s a stratum 2 server that’s been very stable on time: when it syncs with GPS-stabilized clocks every 1024 seconds, it’s rare for it to shift the time more than 10ms. So by syncing to the South American pool, I was able to, more or less, determine the effect of the long-distance, high-latency synchronization:
oxygen ~ # ntpdate -q south-america.pool.ntp.org
server 200.192.232.8, stratum 2, offset 0.021524, delay 0.23042
server 146.83.183.179, stratum 2, offset -0.002081, delay 0.17311
server 201.84.224.130, stratum 3, offset 0.004254, delay 0.19417
26 Apr 00:33:31 ntpdate[5828]: adjust time server 146.83.183.179 offset -0.002081 sec
(First of all, no, my US server is not in that list.) You can see that it selected three servers from the South American pool, and synced to each of them. I had pings of 230ms (0.23042 seconds), 173ms, and 194ms. I had offsets of 21ms, -2ms, and 4ms. Given the three choices, ntpdate deemed the middle the most accurate, indicating that, even with almost 200ms latency crossing continents (or arbitrary divisions thereof), it could be accurate to 2ms.
NTP “subtracts” latency from the times, so that a high-latency connection won’t affect the accuracy of the time. (What does break things, though, is highly-variable, or highly-asymmetric, latency, which is pretty much impossible to “calculate.”) Still, I was surprised by just how good it was.
I then tried a test synchronization to the US pool:
oxygen ~ # ntpdate -q us.pool.ntp.org
server 66.191.139.147, stratum 2, offset 0.001096, delay 0.07080
server 65.111.164.223, stratum 2, offset -0.003190, delay 0.07475
server 66.250.45.2, stratum 3, offset 0.013041, delay 0.07225
server 63.89.76.60, stratum 2, offset 0.005535, delay 0.07397
server 209.67.219.106, stratum 3, offset 0.003419, delay 0.02605
26 Apr 00:34:36 ntpdate[6216]: adjust time server 66.191.139.147 offset 0.001096 sec
This time we got 5 servers (as is normally the case: I think the set of 3 is just given out for groups with only a handful of total servers). Four of them has pings around 70ms, and the last had a ping of 26ms. The middle server had na offset (time difference) of 13ms, but the other four were pretty close. (And when one server is “way” off, NTP disregards it anyway. Plus, it was a stratum 3 mixed in with mostly stratum 2’s, which is another count against it.) It suggested advancing my clock by 1 millisecond. (When the code is good enough to discard a 13ms difference as ‘wildly inaccurate,’ you know it’s good.)
So we have a 1ms “error” in the US, and a 2ms to South America. Africa is served by a mere 5 NTP servers. How did that go?
oxygen ~ # ntpdate -q africa.pool.ntp.org
server 41.223.43.5, stratum 2, offset 0.086558, delay 0.62405
server 196.43.1.14, stratum 3, offset 0.005741, delay 0.32759
server 196.25.1.9, stratum 2, offset -0.006428, delay 0.29601
server 196.43.1.9, stratum 2, offset -0.007126, delay 0.32123
server 196.25.1.1, stratum 2, offset -0.004245, delay 0.29314
26 Apr 00:31:07 ntpdate[4913]: adjust time server 196.25.1.1 offset -0.004245 sec
Oddly, I was served all five servers in the zone. If you look at pings, they ranges from 293ms to 624ms. That’s really bad. And the first server gave terrible time: essentially wanting to advance my clock 87ms. But again, with multiple servers present, NTP did a great job of working out the right time. It ended up trying to move my clock back 4ms.
300ms (best case) pings, going from the US to Africa, and it’s accurate to 4ms?
Some conclusions, caveats, and comments to consider:
- “Accuracy” and “error” are really not appropriate terms. Because the server doesn’t have a time source connected directly (e.g., a GPS receiver with pulse-per-second output, a WWV receiver, or a cesium / rubidium reference recently synced to the atomic clock), the server really doesn’t know the true time. Thus we can only measure how the time differences compare. In this, I essentially just assume that my server has the accurate time, which is a dubious claim.
- The main conclusion here is that NTP is really good at dealing with long pings. The fact that my data is crossing the ocean doesn’t really matter: it can calculate round-trip error. In light of this fact, and ignoring other information, geography is not important.
- The server I took these measurements from sits in a data center on a nice fat backbone to lots of other providers. Thus it could be argued that it may have a much better connection that a home user might. It would be interesting to try these measurements from a normal PC on a “normal” home line.
- Thus, my point isn’t so much that “Geography doesn’t matter” as it is, “Even if geography works against you, you can still get really good time with NTP.”