I’m worried you’ll all think I’ve snapped and become obsessed with time. It’s not quite that bad. But here’s another post about time.

A lot of Windows machines seem to sync to time.windows.com, and Apple has its own time.apple.com service. I come across this interesting (to me) post about Apple’s service, and started doing some looking. First, an important bit of terminology (for those who don’t follow my every post): the stratum of an NTP server is basically its place in a hierarchy of systems. Stratum 1 is the top, meaning that it’s directly connected to an accurate time source (e.g., a GPS or other hyper-accurate time source). Lots and lots of people sync their clocks to Stratum 1 servers, and thus become Stratum 2. And lots of the Stratum 2 servers join the pool, meaning that people who sync to them become stratum 3. With each step down the hierarchy, you increment the stratum by one. The impact of stratum varies: you become more and more removed with each step, which obviously introduces error. But the level of error varies: it’s conceivable that strata 1-3 would all be on the same LAN, but it’s also possible that my stratum 3 server I sync to is sitting on a 100 Mbps line in a data center in Boston, gets it time from a stratum 2 machine with a 128kbps satellite link in Zimbabwe, which gets it time from a stratum 1 on a 3600bps dialup line in Rhodesia. (Is that even a country anymore?) So the “loss” of being several strata down varies somewhere from maybe 1ms up through many seconds.

One final note: the following commands are being run on a node that’s itself a stratum 2 NTP box, so pay attention to the “offset” field. (And note that it’s in seconds, not milliseconds, just to add a healthy dose of confusion.)

# ntpdate -q time.windows.com
server 207.46.197.32, stratum 3, offset 0.016801, delay 0.08435
 9 Mar 22:47:55 ntpdate[22072]: adjust time server 207.46.197.32 offset 0.016801 sec

First, it’s inexplicably a stratum 3 host. This isn’t necessarily bad as I discussed, so much as odd–you’d think that time.windows.com could at the very least be stratum 2, if not holding a GPS itself. (“time.windows.com” may actually be a number of machines sharing an IP, with GeoIP or whatnot.)

For comparison, the nodes I sync to:

#  ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-time-C.timefreq .ACTS.           1 u  142 1024  377   18.854    4.204   0.025
-india.colorado. .ACTS.           1 u   93 1024  377   23.777   11.419   3.751
+rrcs-64-183-56- .GPS.            1 u  408 1024  377   55.427    0.217   1.047
*tick.UH.EDU     .GPS.            1 u  483 1024  377   25.108   -2.053   0.082
+clock.xmission. .GPS.            1 u  145 1024  377   38.306   -0.861   0.019

Pay attention to the “offset” column, which here is in milliseconds. The timeservers range from pulling be back 2 milliseconds to advancing me 11 milliseconds. (Although also note the “-” on the first line, indicating that the +11ms host is considered a fairly bad source. By comparison, the “*” indicates the current ‘best’ server, which set my clock back 2ms.)

Microsoft’s server is trying to pull me 0.016801 seconds, or 16.8ms. As shown above, this is even worse than the server that’s being rejected for being too far off. (Of course, it’s worth repeating that it’s less than 17 milliseconds, which is more than enough accuracy if your goal is to simply keep your clock accurate!)

How about Apple?

# ntpdate -q time.apple.com
server 17.254.0.28, stratum 2, offset 0.004297, delay 0.07193
server 17.254.0.31, stratum 2, offset 0.003697, delay 0.07074
server 17.254.0.26, stratum 2, offset 0.004346, delay 0.07195
server 17.254.0.27, stratum 3, offset 0.004369, delay 0.07195
 9 Mar 23:23:37 ntpdate[4321]: adjust time server 17.254.0.31 offset 0.003697 sec

This one looks different than the Microsoft one: there are four IPs for time.apple.com. All four are kept at stratum 2. The offset here is better: 0.003697 seconds, or 3.7ms. It’s still pulling me in the wrong direction (-2ms was ruled the best, whereas this wants to advance me +4ms), but it’s much closer to accurate.

This got me wondering: Apple has 4 A records for time.apple.com… What does the NTP pool look like?

# ntpdate -q pool.ntp.org
server 67.201.12.252, stratum 3, offset 0.002990, delay 0.05959
server 69.36.240.252, stratum 2, offset 0.003088, delay 0.06898
server 98.172.38.232, stratum 2, offset 0.022841, delay 0.08508
server 209.67.219.106, stratum 3, offset 0.019785, delay 0.02614
server 216.184.20.83, stratum 3, offset 0.012001, delay 0.10208
 9 Mar 23:31:21 ntpdate[7524]: adjust time server 69.36.240.252 offset 0.003088 sec

It returns five hosts. And a quick aside:

;; ANSWER SECTION:
pool.ntp.org.           948     IN      A       209.67.219.106
pool.ntp.org.           948     IN      A       67.201.12.252
pool.ntp.org.           948     IN      A       98.172.38.232
pool.ntp.org.           948     IN      A       69.36.240.252
pool.ntp.org.           948     IN      A       216.184.20.83

They have a long expiry: 948 seconds, or about 16 minutes. Sure enough, asking again gets me the same 5, but with a decremented TTL. They do run GeoIP, though, so my other server is getting a different list, even though both are in the US. (But it keeps the same list, too.) But anyway, back to the ntpdate output…

I’d actually run this earlier, and gotten all stratum 1’s and stratum 2’s, which I was going to post. Now it’s all 2’s and 3’s. The dork in me wants to run this every ttl seconds and keep logs.

This shows where the NTP clock selection algorithm shines. I know from belonging to the pool that we get “monitored” by a server that checks our time a few times an hour and pulls us out of the pool if our servers are off (I think a second is the tolerance). Here, the worst server is 0.022841 seconds (22.8ms) off, and one of the best is picked. (The “best,” the one closest to mine, is actually discounted because it’s a stratum 3, and the stratum 2 one is presumed to be more accurate. Closeness to your own clock is generally not a metric, unless you’re running these on a server that’s already kept to good time.) But the net result is an offset of about 3ms: a slight improvement over Apple, and a big improvement over Microsoft.

Aside: I just ran the Microsoft one again, and its offset had dropped to 2.3ms. So I ran it with Apple and Microsoft in one, letting the NTP algorithm do its magic… Suddenly Microsoft was suggesting a -1ms offset, with Apple pushing a 4ms increase. They’ve all converged a bit, although the time.windows.com one seems to jump around a bit more than the others?

The moral of the story? All of these timeservers are really good if you’re just looking to keep the clock in your system tray right. If you’re a total nut for the right time, the pool is best, followed by Apple, then Microsoft.

Addendum: Microsoft hosts one of NIST’s Stratum 1 servers, which makes it all the stranger that time.microsoft.com is all the way at stratum 3.