<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 23, 2014 at 10:41 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FWIW I disabled pacemaker here and it solved the problem of ntpd not being able to adjust the clock (pacemaker was apparently undoing it). But it is still not *syncing* the clock after the initial sync, it is building up delays over time and then fixing them all at once, like it thinks it's an ntpdate cron job. Apple's config doesn't seem to do anything to make this happen....</div></div></div></div></blockquote><div><br></div><div>Ok, the discussion linked by Lawrence suggests that this is expected; Apple's ntpd syncs once, creates ntp.drift if it does not exist, and effectlvely does nothing afterward, with pacemaker adjusting the time based on that initial ntp.drift. Which does not work: you really need ntp.drift to be calibrated over a period of at least several days before it is reliable, *and* there is always the possibility that hardware behavior changes over time especially as new hardware is "broken in".</div><div><br></div><div>So I will kill off Apple's foo and use ntpd from ports, I think. It may not "save battery", but last I checked iMacs did not have batteries. :)</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>