ntp time drift mavericks

I can confirm that I've been seeing this issue, as have a number a colleagues.

normal running looks like this:

ntpq> assoc

ind assid status conf reach auth condition last_event cnt

===========================================================

1 1308 9034 yes yes none reject reachable 3

2 1309 9054 yes yes none reject reachable 5

3 1310 9014 yes yes none reject reachable 1

4 1311 9014 yes yes none reject reachable 1

5 1312 9014 yes yes none reject reachable 1

ntpq> peer

remote refid st t when poll reach delay offset jitter

==============================================================================

ns02.worldspice 96.237.191.14 2 u 70m 64 377 106.155 -47124. 3196.04

linode.appus.or 127.67.113.92 2 u 253 64 377 37.995 -47656. 3216.27

tux.brhelwig.co 127.67.113.92 2 u 70m 64 377 70.011 -47113. 3190.69

ntp1.communicat 128.2.1.22 3 u 70m 64 377 91.882 -47113. 3190.88

time.apple.com 17.107.131.11 2 u 224m 512 377 44.175 -45839. 8133.14

after restarting NTP:

ntpq> assoc

ind assid status conf reach auth condition last_event cnt

===========================================================

1 54893 9024 yes yes none reject reachable 2

2 54894 9024 yes yes none reject reachable 2

3 54895 9024 yes yes none reject reachable 2

4 54896 9024 yes yes none reject reachable 2

5 54897 963a yes yes none sys.peer sys_peer 3

ntpq> peer

remote refid st t when poll reach delay offset jitter

==============================================================================

4.53.160.75 204.9.54.119 2 u 22 64 1 78.086 -0.117 0.001

rev-18-85-44-59 18.85.44.61 3 u 21 64 1 99.626 2.327 0.001

198.52.198.248 66.228.59.187 3 u 20 64 1 88.126 13.910 0.001

ns20.alltraders 127.67.113.92 2 u 19 64 1 38.238 9.258 0.001

*time.apple.com 17.107.131.11 2 u 11 512 1 44.493 3.408 0.536

For those wondering why Apple is going through all this trouble with a customized ntpd and new pacemaker daemon, you might want to read the section of John Siracusa's Mavericks review starting here:

http://arstechnica.com/apple/2013/10/os-x-10-9/12/

The relevant info takes several pages to cover (in typical Siracusa style), but I believe it explains what all these ntp changes and the addition of pacemaker are all about: energy savings. It might also explain why the specified ntp polling intervals seem to be ignored.

In response to Jack840's question, FWIW, I've been seeing clock drift on a Mac Mini 2013 running OS X Mavericks but I do not see the clock drift on a Mac Mini 2011 running OS X Mavericks with OS X Server 3...

Interesting reading and maybe it is true that it has to do with energy savings, but that should not be the reason why ntpd behaves bad.

I am now testing the old 10.8.5 ntpd on my late 2012 27" iMac which I copied from an older Time Machine backup and this version, which has the same number as the Mavericks version (why because it is a totally different one), works pretty well in combination with pacemaker.

BTW on a medio 2011 iMac ntpd works ok, but does not listen to the poll interval.

Given the response from tux_arkhitekton and NL, it appears that the newest ntpd/pacemaker is working well on some machines and not on others.

As for me, I have reverted to the ntpd version that was delivered with OS 10.8.5 and I have also disabled pacemaker. This seems to work well and my clock offset is typically below 0.005 seconds (5 milliseconds). This is about the best I can expect. I am using a time server on the Internet (but nearby) to check the offset with ntpdate.

ntpdate -q your.timeserver.here

server xxx.xxx.xxx.xxx, stratum 2, offset 0.004544, delay 0.06187

3 Jan 08:15:49 ntpdate[55293]: adjust time server xxx.xxx.xxx.xxx offset 0.004544 sec

For now I am inclined to wait for Apple to solve this problem.

Apple, this is embarrassing that you haven't solved (or even responded) to this more than two months later.

What is it we actually pay you for? If I wanted to compile my own software just to have a functional system, I sure wouldn't be paying the Apple tax.

Apple doesn’t routinely monitor the discussions.

Send Apple feedback. They won't answer, but at least will know there is a problem. If enough people send feedback, it may get the problem solved sooner.

Feedback

Not likely. I have an open support request that hasn't been responded to in two months about this very issue.

I didn't want to recompile ntp or start messing with system files that would end up getting overwritten on the next system update, so here's the solution I came up with.

I have a cron job running every 4 hours. In terminal, type

crontab -e

then, on the first line, type:

0 */4 * * * sudo /usr/sbin/ntpdate -u time.apple.com

(make sure there is a carriage return at the end)

This will sync your clock to the apple time servers every 4 hours. I had to play around with it to get it where it actually executed, so ymmv, but at least I'm not messing with system files. I have my cron set up where it actually e-mails me, so I've been monitoring the output, and have been adjusting more than 1 second each time it runs, which means I've been losing 6 seconds per day with this bug. That's bad even for a cheap alarm clock from WalMart.

to extend your analogy, you have a cheap alarm clock from Walmart, and you've bought another clock that you use to set your cheap clock with. Why put the cheap clock in the loop?

In other words, you are running NTP in an attempt to keep time, then running ntpdate to update the system time because NTP isn't working. Which also begs the question: how will you know when Apple fixes the NTP issue and your cron is superfluous or even counterproductive?

If, on the other hand, you run the pre-Mavericks ntp binary, and Apple updates ntp, then you will get the new version and you won't have a cron that is interfering with NTP. And if Apple updates NTP and doesn't fix the problem, you could just move the pre-Mavericks NTP back into place.

Just thinking out loud here ;-)

You wouldn't think it was so hard to keep system time. But NTP is a complex solution to a complex problem based on a simple question: what time is it?

Question.. was this fixed in 10.9.2?

The basic problem is that Apple have stopped ntpd from actually making the appropriate system calls to adjust time in ntpd and placed them in pacemaker. They are using ntpd to maintain the drift file - and then pacemaker appears to use the drift file to maintain the clock. In my view this is basically an unstable system - it doesn't allow for convergence of the clock with the ticks that ntpd sees. Ntpd may be old, and apparently complex, but it's a clever and a really well constructed system but is broken by the removal of its ability to influence events. The ntpd/pacemaker combination may be OK on a laptop which effectively starts and stops ntpd frequently, but really is bad news on a desktop machine that's on all the time. On my iMac I found that over some period the drift file varies wildly - and eventually ntpd just gives up and rejects all its source clocks as 'bad tickers' (which was reported in this thread) - so things just free run.

For 10.9.1, I obtained Apple's code for ntpd - which is available (http://www.apple.com/opensource/ look for ntp and then ntp-86) and is compilable using Xcode. I uncommented the system calls that had been removed - and moved /usr/libexec/pacemaker out of the way. My recompiled ntpd has worked to keep time stable and accurate.

I installed 10.9.2 about an hour ago (having undone the changes I made for 10.9.1), and there is a new ntpd (and ancillary programs) but it looks that 10.9.2's ntpd is still not using the system calls and still relies on pacemaker.

I had filed an Apple bug on this using Bug Reporter in December - but it was a duplicate (sigh) so I really have no idea about what changes Apple may have made for 10.9.2. One reason for changes may be the recent spate of DOS attacks using ntp as the protocol of choice.

So I guess I'll spend the next week or so seeing what is happening on the machine and waiting for Apple to update the opensource archive.

Peter Collinson wrote:

One reason for changes may be the recent spate of DOS attacks using ntp as the protocol of choice.

This would only happen when your machine is a public time server with open ports to the internet and who would want to serve time which such a bad ntpd implementation?

Just replace /usr/sbin/nptd with the pre-Mavericks (Mountain Lion) version from a "Time Machine Backup" and do:

sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist

and

sudo launchctl load /System/Library/LaunchDaemons/org.ntp.ntpd.plist

and you are good to go, even with Pacemaker running also.

Edit: And I forgot to tell that it is also a good idea to delete the /var/db/ntp.drift file before restarting the daemon because it can contain ±500.00 value

Message was edited by: from NL

Well I guess Apple do have the code running on 'Server' and may wish to offer an NTP service from a Mac platform. Someone has to have ntpd with open ports somewhere otherwise there would be no references.

Not so sure that you should have an activated ntpd and pacemaker running at the same time, both will be attempting to mess with the adjtime system call - which isn't actually a great idea. It may work because pacemaker doesn't fiddle with the clock settings too often.

I just did

sudo mv /usr/libexec/pacemaker /usr/libexec/pacemaker.osx

and launchtl whimpers but all is OK.

Peter Collinson wrote:

Not so sure that you should have an activated ntpd and pacemaker running at the same time, both will be attempting to mess with the adjtime system call - which isn't actually a great idea. It may work because pacemaker doesn't fiddle with the clock settings too often.

I just did

sudo mv /usr/libexec/pacemaker /usr/libexec/pacemaker.osx

and launchtl whimpers but all is OK.

I had no problems running ntpd together with Pacemaker for about 2 months and I know they both do a system call to adjtime. I don't want to make too many changes to my system. I have tested with Pacemaker disabled and the "Mountain Lion ntpd" but that made no difference. I left Pacemaker running after that testing.

Here's the new ntpd under 10.9.2:

ntpq> assoc

ind assid status conf reach auth condition last_event cnt
===========================================================
1 29328 9054 yes yes none reject reachable 5
2 29329 9034 yes yes none reject reachable 3
3 29330 9014 yes yes none reject reachable 1
4 29331 9014 yes yes none reject reachable 1
5 29332 9014 yes yes none reject reachable 1

ntpq> peer
remote refid st t when poll reach delay offset jitter
==============================================================================
sola-dal-09.ser 184.173.173.205 3 u 1201 128 7 80.345 137.321 109.654
xen1.rack911.co 204.2.134.163 3 u 1322 128 7 54.072 138.155 104.732
yurizoku.tk 200.98.196.212 2 u 65m 64 2 101.607 62.105 0.001
equinox.nj.us.s 58.32.204.127 2 u 65m 64 2 101.796 63.893 0.001
time5.apple.com 17.107.131.11 2 u 108m 512 1 38.854 1.769 0.001

Looks like the default ntpd under 10.9.1, that is, broken.

I've replaced ntpd with the pre-Mavericks version, removed the drift file, and lauchcntl unload/loaded, and I see:

# ntpq

ntpq> assoc

ntpq: read: Connection refused

# ps -ef|grep ntp|egrep -v grep

#

Not good.