what was up with ntp again?

[Brandon Allbery]

On Tue, Apr 28, 2015 at 8:14 PM, Jan Stary <hans at stare.cz> wrote:

> 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?
>

This is my understanding, yes. ntpd handles the network stuff and pacemaker
does the clock updates via a mechanism that uses fewer context switches and
supposedly is gentler on running processes (so they're less likely to have
a storm of activity when the time changes under them and they're using a
time-based event queue or something). This could also potentially be more
secure, but I don't know if Apple bothers with that.


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

I don't know, and reports vary a lot; some claim it seems to use more power
than the old ntpd.


> 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)?
>

Copyrights are from ntp.org; I assume parts are at least stubbed out.


> 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).
>

So someone has revived it. It had been dead for several years.

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

Determines clock drift by comparing local time to time determined by
polling NTP servers / peers (tracking time differentials between those
polls, which helps compensate for vagaries of packet delivery time over the
network), and communicates this to pacemaker. The NTP polling stuff and
computing a drift can be fairly complex ("drift" is overly simplistic and
best considered a starting point; in reality it's a system of differential
equations, not a single value...), and it makes sense to offload those from
other aspects of timekeeping (indeed it makes sense to split them entirely
if you have either a way to minimize the time spent in IPC *or* no need for
the somewhat insane nanosecond-scale timekeeping ntpd tries to maintain.

pacemaker *only* does the local time update stuff, not the network-based
stuff or determining the exact updates to be done; it gets those from ntpd.
Flip side, ntpd only knows two ways to update the clock, one is a
sledgehammer and the other a tiny skew that takes forever for the update to
be applied --- and, if you read that presentation about ntimed, hooking new
ones (or new anything else for that matter) into ntpd is *painful*. Minimal
changes to disable some parts of ntpd and then reimplementing those parts
externally makes a lot of sense, unless you are in a position to burn the
whole thing to the ground and start from scratch.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150428/0d4dd60c/attachment.html>