what was up with ntp again?

[Jan Stary]

> > To put it in context: my computers all use the same ntp server (
> > fr.ntp.pool.org) so that in theory they share the same clock. Turns out
> > that my Mac is about 5min (a bit over 300 seconds) ahead of the others, and
> > also of Bradley's VM. I've tried deactivating and reactivating (after
> > setting time manually) network time in System Preferences, but it just
> > jumps back to the future.
> >
> > Is this related to the issue that was discussed a while back, and to
> > Apple's conflicting service (pacekeeper?)?

>     sudo launchctl
> unload /System/Library/LaunchDaemons/com.apple.pacemaker.plist
>     sudo rm /etc/ntp.drift
>     sudo launchctl stop org.ntp.ntpd
>     # wait an hour or so for ntpd to establish the current drift
>     sudo
> launchctl load /System/Library/LaunchDaemons/com.apple.pacemaker.plist

So ntpd and pacemaker are supposed to run simultaneously?
What exactly is pacemaker's job if I have ntpd running?

> The longer version I'll briefly gloss: Apple replaced traditional ntp with
> one that uses less power and is more laptop friendly, when it works right.

Does "traditional ntp" mean ntp.org's implementation?
Is "pacemaker" the new implementation, or is there
an "Apple ntpd" now with the "pacemaker" on top?

Can you please give some pointers to how much less power
the new ntpd uses and how much more "laptop friendly" it is?

> But it assumes that the clock drift of a brand new machine is the same as
> that of a fully burned-in and deployed machine, which it might well not be.
> The above commands are a "quick reset" of the clock drift, but as Apple
> removed some parts of ntp they may not be sufficient to determine the
> current clock drift; in that case, you need to use a full ntpd to
> characterize the drift, then switch back to Apple's for the improved
> performance and power management.

So the Apple NTPd is a stripped down ntp.org implementation?
Or is it a different implementation, decidedly omitting some
aspects of NTP (nanosecond precission)?

> The real fix for this is someone needs to rehabilitate open(s)ntp, which is
> lighter weight by design but these days only supported on OpenBSD. I'm not
> holding my breath.

The last release of http://www.openntpd.org/portable.html
happened about a month ago and explicitly states that it is
"known to build and work" on Mac OS X (10.9).

> > When I tried using the Apple NTP and pacemaker, what I discovered
> > essentially is that NTP does NO clock adjustment at all. All the clock
> > adjustment comes from pacemaker. Unfortunately, it did not do a good job of
> > synchronizing for me. In particular, the Apple NTP was never able to get
> > past a poll of 256, and almost always was at 64. The drift file wanted to
> > be over 500 no matter what I did with the stock config.
> 
> Yes, this is why I added the caveat about possibly needing full ntpd. Some
> people *have* had it work; Apple's ntpd doesn't update the time itself, but
> can determine drift in simple cases, and as this doesn't require installing
> more software it's preferred. If it doesn't work then you're stuck with
> installing full ntpd at least temporarily.

I don't get it. If Apple's ntpd does not update the time,
what does it do?

> (Somewhere on my rather large to-do list is writing this up in detail
> somewhere, probably the MacPorts Trac wiki.)

That would be most appreciated.

On Mar 23 12:43:04, dluke at geeklair.net wrote:
> There's also work going on a new daemon (ntimed) that will likely eventually be the 'best' ntpd replacement (it doesn't work on Mac OS X yet either, though).

And it won't work on OS X for some time, judging by page 35 of
https://fosdem.org/2015/schedule/event/ntimed_ntpd_replacement/attachments/slides/788/export/events/attachments/ntimed_ntpd_replacement/slides/788/ntimed.pdf


	Jan