what was up with ntp again?

[Brandon Allbery]

On Mon, Mar 23, 2015 at 10:02 AM, René J.V. <rjvbertin at gmail.com> wrote:

> On Monday March 23 2015 09:31:50 Brandon Allbery wrote:
> >    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
>
> I don't get point 4: how can ntpd determine anything if it's not running?
>

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

>can be done if needed. But full ntpd is not actually suitable for anything
> >but certain scientific applications that require nanosecond accuracy; you
> >pay quite a bit in CPU and power for that accuracy, and there are very few
>
> 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?
>

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


> >applications that require more than millisecond clock accuracy. One
> wonders
> >how much better Linux etc. would perform if they didn't use full ntpd.)
>
> Again I never noticed any such performance issues ... but apparently
> that's because my Ubuntu hosts don't use ntp but something called ntpdate:
>

ntpdate is a one-shot, sometimes run from cron. Don't tell the ntp folks,
they'll have a screaming fit :)

I expect this is Ubuntu's answer to the weight of ntpd.

Understand:

- ntpd has a fairly hefty memory footprint;
- this memory is usually mlockall()ed, so that it can't be swapped,
complicating OS memory management and potentially fragmenting main memory;
- 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);
- 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.

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

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.

-- 
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/20150323/53143528/attachment.html>