<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 23, 2015 at 10:02 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday March 23 2015 09:31:50 Brandon Allbery wrote:<br><span class="">> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.pacemaker.plist<br>
> sudo rm /etc/ntp.drift<br>
> sudo launchctl stop org.ntp.ntpd<br>
> # wait an hour or so for ntpd to establish the current drift<br>
> sudo<br>
>launchctl load /System/Library/LaunchDaemons/com.apple.pacemaker.plist<br>
<br>
</span>I don't get point 4: how can ntpd determine anything if it's not running?<br></blockquote><div><br></div><div>For a launchd daemon job, "stop" doesn't actually fully stop it --- only "unload" does (hence steps 1 and 5). "launchctl stop" does in fact stop it for a moment, but because it's configured to always be running, launchd immediately restarts it. So "launchctl stop" turns out to be a convenient way to "bounce" a service. (It's really intended for use with "launchctl start" on-demand jobs.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>can be done if needed. But full ntpd is not actually suitable for anything<br>
>but certain scientific applications that require nanosecond accuracy; you<br>
>pay quite a bit in CPU and power for that accuracy, and there are very few<br>
<br>
</span>Was the ntpd shipped with OS X 10.6 a full one? If not, it might be possible to go back to using that one, no?<br></blockquote><div><br></div><div>It was. If you're on post-10.6, though, you're better off just installing ntpd from MacPorts and configuring /opt/local/etc/ntp.conf (possibly by copying /etc/ntp.conf over it).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>applications that require more than millisecond clock accuracy. One wonders<br>
>how much better Linux etc. would perform if they didn't use full ntpd.)<br>
<br>
</span>Again I never noticed any such performance issues ... but apparently that's because my Ubuntu hosts don't use ntp but something called ntpdate:<br></blockquote><div><br></div><div>ntpdate is a one-shot, sometimes run from cron. Don't tell the ntp folks, they'll have a screaming fit :)</div><div><br>I expect this is Ubuntu's answer to the weight of ntpd.</div><div><br></div><div>Understand:</div><div><br></div><div>- ntpd has a fairly hefty memory footprint;</div><div>- this memory is usually mlockall()ed, so that it can't be swapped, complicating OS memory management and potentially fragmenting main memory;</div><div>- it runs at realtime priority when it can, stealing a significant number of CPU cycles whenever it wants (and, as I understand it, steals even more if *not* at rtprio to compensate);</div><div>- it can also do a considerable amount of network traffic (again, at realtime priority when it can), although this usually settles down once it has figured out the clock drift.</div><div><br></div><div>I will grant that post-10.6 can be slower, but Apple's ntpd is not the cause. (In fact, there isn't a single "the cause", it's little bits all over the place that add up.)</div></div><div><br></div><div>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.</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>