On Tue, Apr 28, 2015 at 8:14 PM, Jan Stary <[email protected]> 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 [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
