2

I'm using ICMP time stamping on my mid-2013 MacBook Air, and I need my clock to have an accuracy of no worse than 1ms.

I see that ntpd is running, with the default settings, and /etc/ntp.conf contains just one line, server time.apple.com, without even any comments.

However, if I run ntpdate -d time.apple.com (or ntpdate -d ntp1.yycix.ca, which produces the same offset reading for any given time as time.apple.com farm does), always as a non-root user, I'm often getting the reading that my clock is offset by as much as 6ms, or, most often around 4ms (sometimes 0ms, but very rarely).

Why is this happening? I'm not even rebooting my MacBook, it runs 24/7, plugged in, why is its ntpd not keeping the time correctly?

Syslog has the following:

% syslog | fgrep ntp | fgrep -v sudo | tail
Nov 19 12:59:30 mba.cnst ntpd[86861] <Notice>: proto: precision = 1.000 usec

Last I checked, 1.000 usec is no worse than 1 us, which is 0.001ms, or 0.000001s; why does it claim that precision is 0.001ms, when in reality the clock is offset by as much as 6ms?

2

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.

  • Great answer. It looks like this will be required also on 10.9 where ntpd runs to calculate drift only, and that the new pacemaker program actually does the clock correction in accordance with battery and wall power settings. – bmike Jan 19 '14 at 18:12
  • Please update your answer to point people to pool.ntp.org/en There is no need to have everyone's macbooks overloading the stratum one time servers. – dfc Mar 15 '14 at 14:07
1

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.
 */
  • This is big news to me! Do you have any source to back this up? My understanding of the x86 architecture is that there is a separate timecounter, unrelated to the CPU, which keeps track of time. E.g. mdoc.su/f/hpet.4. – cnst Nov 26 '13 at 2:59
  • @cnst I've linked to the source code on Mavericks, but my speculation about less precision is just that - speculation and not something I have hard data on. My experience with accurate timekeeping (SCADA systems) uses custom code and custom external hardware, as opposed to ntpd code and clocks from CPU / motherboard manufacturers. – bmike Nov 26 '13 at 3:16
  • The source code you've linked is from ntpd, and has not much to do with the actual system clock or HPET, let alone support your conjecture that MacBooks cannot keep the time accurate. HPET is there for a reason; "advanced CPU clock rate shifting" is not any excuse in 2013, and is nothing new. – cnst Nov 26 '13 at 3:30
  • Also, I'm using 10.8, not 10.9. – cnst Nov 26 '13 at 3:31
  • 1
    Modern CPUs do scale their frequencies for turbo-boost or power-saving. However, they also tend to have a constant-rate timestamp counter available, which ticks at the same rate regardless of the operating frequency. This is true since about the Pentium 4, see: en.wikipedia.org/wiki/… – thenickdude Feb 9 '17 at 8:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .