ntpd: consistently incorrect time on mid-2013 MacBook Air

Solution 1:

The server keyword of ntp.conf(5) would appear to configure only a single server, even if the provided hostname resolves to more than one IP address.

It would appear that the specific server that was being selected is a PoS.

mba: {4899} ntpdc -s ; ntpdc -sn
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*time.apple.com  129.xx.xxx.xxx   2 4096  377 0.07106  0.000248 0.24763
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*17.151.16.22    129.xx.xxx.xxx   2 4096  377 0.07106  0.000248 0.24763
mba: {4900} ntpdate -d 17.151.16.22 |& tail -1 ; \
?           ntpdate -d time.apple.com |& tail -1 ; \
?           ntpdate -d ntp1.yycix.ca |& tail -1
26 Nov 01:49:13 ntpdate[97738]: adjust time server 17.151.16.22 offset -0.000318 sec
26 Nov 01:49:16 ntpdate[97740]: adjust time server 17.171.4.15 offset -0.006493 sec
26 Nov 01:49:16 ntpdate[97742]: adjust time server 192.75.191.6 offset -0.006443 sec
mba: {4901}

Going to Date & Time Preferences, and providing a comma-separated list of valid NTP servers seems to fix the issue.

Providing a comma-separated list in GUI results in several server entries in /etc/ntp.conf, although you have to make sure that the hostnames themselves are different (otherwise, the repeated hostnames don't result in any extra actual servers being selected, as per ntpq -p).

mba: {5104} cat /etc/ntp.conf
server ntp1.yycix.ca
server time.nist.gov
server tick.usask.ca
server tock.usask.ca
server clock.nyc.he.net
mba: {5105} ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.yycix.ca   .GPS.            1 u  138  512  377   56.517   -0.662   0.319
-2610:20:6f15:15 .ACTS.           1 u  117  512  377   27.975   -1.774   0.989
+tick.usask.ca   .GPS.            1 u  456  512  377   31.388   -0.636   0.135
*tock.usask.ca   .GPS.            1 u  124  512  377   31.486   -0.864   0.413
-clock.nyc.he.ne .CDMA.           1 u  139  512  377   26.860   -2.161   0.194
mba: {5106}

A list of servers is available at http://support.ntp.org/servers; you have to try to select the servers that are close to you, especially not just geographically, but network-wise.

Solution 2:

The latest processors have some quite advanced CPU clock rate shifting that might make a time keeping algorithm like ntpd be off 10ms or more even if you have the optimal settings and a proper drift file. Add to that App Nap, timer coalescing and other efficiency changes to Mavericks and I wouldn't be surprised if some of those affected timekeeping as seen by a process that runs on the CPU.

Now, the individual clock you have on your Mac doesn't really care for CPU timing and sleep, but the process that corrects to an external source might. From the excellent comments below - it's likely the time keeping hardware is isolated from any CPU power savings - https://en.wikipedia.org/wiki/Time_Stamp_Counter#Implementation_in_various_processors

If your clock is good enough for you - no need to get into the details here or worry about GPS synchronized clock or real time OS level precision and accuracy. The hardware is clearly capable of being within 10s of milliseconds to an external source with the typical ntp infrastructure in most cases.

My understanding is that debug message is an internally rate-limiting number where the ntpd code is checking how fast the CPU runs, and not some report that you are in fact 1.000 usec from reality or even some external reference source.

See the comments above the procedure default_get_precision(void) where it states:

/*
 * This routine calculates the system precision, defined as the minimum
 * of a sequence of differences between successive readings of the
 * system clock. However, if the system clock can be read more than once
 * during a tick interval, the difference can be zero or one LSB unit,
 * where the LSB corresponds to one nanosecond or one microsecond.
 * Conceivably, if some other process preempts this one and reads the
 * clock, the difference can be more than one LSB unit.
 *
 * For hardware clock frequencies of 10 MHz or less, we assume the
 * logical clock advances only at the hardware clock tick. For higher
 * frequencies, we assume the logical clock can advance no more than 100
 * nanoseconds between ticks.
 */