ntp time drift mavericks

I've been following this and other 10.9.x NTP discussions for a couple months, and I've felt the same frustration. I've attempted many fixes, trying to use as much of the existing OS components as possible. I found no way to make the the 10.9.x ntpd work, and decided to directly use ntp.org's distribution. Moreover, pacemaker was unsalvageable and provides no value to me, so I've disabled it. Yes, I understand why Apple created pacemaker and hobbled ntpd, but the Mavericks NTP ecosystem Is simply broken.

The solution that works for me, which I strongly recommend, isn't trivial: unload pacemaker, download/build/install a clean copy of ntpd, modify /usr/libexec/ntp-wrapper to use the new ntpd, manually update /etc/ntp.conf. I have had three Macs running smoothly with this set of changes for weeks so I'm very comfortable recommending this approach.

I'd much prefer an Apple solution, but seeing as 10.9.2 didn't fix the core problem, I've taken matters into my own hands. FWIW, 10.9.2 did address a minor issue with ntp-wrapper not correctly parsing ntp.conf server entries.

Sorry to link outside of This forum, but I've tried to give more details here: https://atmythoughts-v2.squarespace.com/living-in-a-tech-family-blog/2014/2/28/w hat-time-is-it.

A few days ago and after a lot of watching, testing and reading I decided to go the tough road and did a brand new system install of Mavericks 10.9.2 on my late 2012 iMac combined with a SMC, PRAM reset.

This means I did not recover from a "Time Machine Backup". I copied my visual user directory to the new installation, so without settings (Library folder), but I am not sure that it would make a difference, but it keeps me alert of my all my application settings by walking them through again. Every application and plugin was installed again manuallly. It takes a few days to recover😟

And finally my system runs again with the Mavericks "ntpd" and "pacemaker". Do not pay attention though to the output of "ntpq" commands, because ntpd is only used to calculate the drift value, but ntpd's behaviour changed dramatically to accomodate to Apple's extraordinary standards and way of doing things😉. It all has to do with energy savings. I use the "ntpdate -d your.timeserver.com" to watch the offset every now and then or you can go to http://time.is

In the past I fiddled with the "pmset" values on my computer and that could be the cause of all the troubles with "ntpd".

I hope to help other people with this information.

Not working for me on my MacBook Pro 15" Retina (Late 2013). Failed on every point release of Mavericks. On my other three macs (Mac Pro, Mac Mini, MacBook Aire) it's not working either. It will keep sync for three or four hours then drops sync and that's the end of it. I can't even get it to keep sync with a GPS network time server that I had on the same subnet.

So on all my boxes I clicked off "Set date and time automatically" in "Date & TIme" in "System Preferences" to kill ntpd/pacemaker and set up a cron job to run ntpdate every hour.

I've tried everything short of a complete reinstall which I'm not going to do. I've been working with *NIX since 1985 and I shouldn't have to spend precious hours doing a complete reinstall to get a basic component like NTP to work. Come on Apple!!!

What drew me to the Mac was it's BSD base and that most of the *NIX functionality was left intact. The combination of a solid foundation and all those productivity apps was a wonderful thing. And *NIX is a beautiful thing (IMHO) and I hope Apple doesn't drift too far like their current version of NTP. 😟

I've restored NTP sanity by following the "compile your own NTP" path. It was certainly quicker and easier than a clean install, and it does work.

Looking forward to Apple getting this sorted.

tenntux, I agree with the frustration about Apple breaking a basic component of *NIX. However, since Mac OSX is *NIX, you at least have the option to get the true NTP distribution and load it on your system. Yeah, it's a bit of a pain, but, for me at least, it's good to flex those *NIX muscles from time to time. 🙂

Is anyone using the MacPort version of ntpd?

Thanks.

Thanks!!! This has fixed the problem for me!

I reported the problem to Apple, hoping they will fix it soon (no later than in the 10.9.3-release).

Sure hope everyone who has this problem and reads this post will/did report the problem too!

(http://www.apple.com/feedback/macosx.html)

I went one step further by installing a program "Sleepwatcher". As the name says this program watches your systems sleep and wake states.

I am not going into detail here because the installation is pretty straightforward, but the /etc/rc.sleep script contains:

#!/bin/sh

# script for /Library/LaunchDaemons/de.bernhard-baehr.sleepwatcher.plist

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

and the /etc/rc.wakeup script contains:

#!/bin/sh

# script for /Library/LaunchDaemons/de.bernhard-baehr.sleepwatcher.plist

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

Furthermore I have disabled with "pmset" standby mode and in my energy settings I have enabled network access but not powernap.

Together with a Raspberry PI Stratum 1 clock at my home I now have very good results with the standard Mavericks NTP daemon.

It appears that the 10.9.3 update fixed the issue. At least, so far I haven't seen any significant clock-drifting, while before that patch my clock would be several minutes ahead each morning.

10.9.3 hasn't fixed it for me. I've got a drift of ~2-3 seconds (not sure where to check, using visual comparison with clocks on other computers).

Agreed. I've tried Apple's new binary version of ntp - which does nothing to adjust the clock - and the new pacemaker. I find that my compiled version of ntp (Apple version 86) is a factor of 100 better at syncing to my ntp server than the 10.9.3 standard combination of ntp/pacemaker. I 'kill' pacemaker by renaming it and killing the process. Here's sntp looking at my ntp server:

2014 May 29 19:00:36.885401 -0.004001 +/- 0.107727 secs

The -0.004001 is the difference between my system time and the reference clock - which of course is +/- the error.

I was getting regular sync comparisons of +0.3 with the Apple ntp/pacemaker combination. Now 0.3 is better than it was, it should keep my clock in sync for humans, but not that good when syncing filesystems and other electronic times. To be honest, I've not really done an exhaustive long running test on this, because it didn't seem that good so I reverted to something that worked.

Apple have put out a version of their version 88 on opensource.apple.com - which has removed lots of code that appears to be intended to cope with systems that go to sleep - and doesn't include an easy way of turning on adjtime again. So I am still using my compiled version of their version 86.

I remain really dubious that the Apple approach will ever work properly.

I'm disappointed that Apple let this slide by verification testing back on 10.9.0 and then every point release since then. And 10.9.3 ntp/pacemaker is broken as well, failing to keep sync with time.apple.com or any other server I threw at it including a GPS time server on the same subnet.

So what I did was install the MacPort ntp port, version 4.2.6p5, and it is working great on all my Macs. This way, I'll snag any ntp updates when I do a "port upgrade outdated" in the future.

These two easy steps fixed my MAVS clock sync problem:

1. replace /usr/sbin/ntpd from 10.8.5 Time Machine Backup

2. permanently unload /System/Library/LaunchDaemons/com.apple.pacemaker.plist

done.

I simply created a .plist file for launchd!

The text below should become

/Library/LaunchAgents/fixclock.plist

and it is run every 24 hours and upon logging in (parameters you can change if you'd like). To get this process to start without logging out and back in, you can do

launchctl load /Library/LaunchAgents/fixclock.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Label</key>

<string>fixclock</string>

<key>ProgramArguments</key>

<array>

<string>/usr/bin/sudo</string>

<string>/usr/sbin/ntpdate</string>

<string>-u</string>

<string>time.apple.com</string>

</array>

<key>RunAtLoad</key>

<true/>

<key>StartInterval</key>

<integer>86400</integer>

</dict>

</plist>

Correction!

In order for this to run correctly, it should be put into

/Library/LaunchDaemons/

NOT

/Library/LaunchAgents/

/Library/LaunchDaemons/ is run as root and is loaded at system boot. Because it's loaded at boot, I also set "RunAtLoad" to false, because my Mac mini always naturally fixes the clock at boot (and when coming back from sleep).