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 126.96.36.199, stratum 2, offset 0.021524, delay 0.23042 server 188.8.131.52, stratum 2, offset -0.002081, delay 0.17311 server 184.108.40.206, stratum 3, offset 0.004254, delay 0.19417 26 Apr 00:33:31 ntpdate: adjust time server 220.127.116.11 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 18.104.22.168, stratum 2, offset 0.001096, delay 0.07080 server 22.214.171.124, stratum 2, offset -0.003190, delay 0.07475 server 126.96.36.199, stratum 3, offset 0.013041, delay 0.07225 server 188.8.131.52, stratum 2, offset 0.005535, delay 0.07397 server 184.108.40.206, stratum 3, offset 0.003419, delay 0.02605 26 Apr 00:34:36 ntpdate: adjust time server 220.127.116.11 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 18.104.22.168, stratum 2, offset 0.086558, delay 0.62405 server 22.214.171.124, stratum 3, offset 0.005741, delay 0.32759 server 126.96.36.199, stratum 2, offset -0.006428, delay 0.29601 server 188.8.131.52, stratum 2, offset -0.007126, delay 0.32123 server 184.108.40.206, stratum 2, offset -0.004245, delay 0.29314 26 Apr 00:31:07 ntpdate: adjust time server 220.127.116.11 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.”