On Mon, Mar 23, 2015 at 10:02 AM, René J.V. <[email protected]> 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 [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
