Date: Thu, 12 Oct 2017 16:44:55 -0400 From: "Karl Vogel" <vogelke@pobox.com> To: freebsd-questions@freebsd.org Subject: Re: Another 11.1-RELEASE install minor annoyance (ntpd) Message-ID: <20171012204455.GA10740@bsd118.wpafb.af.mil> In-Reply-To: <CACArijD0LgS731K7Xdh%2BOcQ1Cicx0k9yzBKiVniW74b2WosmUA@mail.gmail.com> References: <CACArijC-urzJYRuA9TanUjan5EFRcStMr=rQ%2BgmcRD_KO6gzAA@mail.gmail.com> <3967.1507825257@segfault.tristatelogic.com> <CACArijD0LgS731K7Xdh%2BOcQ1Cicx0k9yzBKiVniW74b2WosmUA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Some NTP observations: ntpdate can be a lifesaver. Sometimes after
installing a new system, I'll see tons of crap dumped in the system logs:
ntpd[743]: frequency error -512 PPM exceeds tolerance 500 PPM
The only workaround I've found is to run ntpdate every 30/60 minutes
via cron. I'm pretty sure the clock chip is just too cheap to work
and play nicely with ntpd. Setting the tolerance higher using (say)
"ntptime -f 520" hasn't worked.
Also, you may shoot yourself in the foot if you use a lot of servers:
http://lists.centos.org/pipermail/centos/2010-August/098092.html
Date drift and ntpd
Warren Young <warren@etr-usa.com>
Thu Aug 12 17:41:17 EDT 2010
Some HOWTOs tell you that more time servers is better, on a standard
knee-jerk redundancy theory, but they're ignoring two things.
First, you already have a fallback: the system's built-in clock.
It's perfectly fine to run on that while you ride out your time server's
downtime.
Second, ntpd, internally, is built on a phase-locked loop, which is
supposed to stabilize its time corrections in the face of jitter and other
bad things out in the real world. Like anything based on a negative
feedback loop, however, it can be destablized with certain inputs.
Giving ntpd two or more servers is a pretty good way to destabilize its
PLL in the real, non-ideal world we find on the modern Internet.
To anyone considering flaming me, please read this first:
http://queue.acm.org/detail.cfm?id=1773943
At minimum, read the section "One server is enough". The bit on PLLs
about halfway down is also directly relevant.
In the "One server is enough" section:
So far we have discussed synchronizing to a single server. Surely one
could connect to multiple servers and select among them to obtain even
better results? In principle this is true; in Internet practice, at
least with the current state of the art, it is most definitely not,
for two reasons.
Most fundamentally, switching servers implies a change in path asymmetry
and hence a jump in the clock. Imagine a server-selection algorithm
that is moving around among candidate servers of similar quality.
The result is constant jumping?a classic case of asymmetry jitter.
Such jitter is not hard to observe in ntpd, where a connection to
multiple peers is in fact recommended.
Second, once performance is tuned to close to system and network noise
limits, any disruption at all will downgrade it. Ceasing to query a
server for a time and then returning to it, for example, qualifies as
a moderate to large disruption.
The take-home message for administrators is this: if you want to improve
your system clock performance, just make sure the configuration points
only to a single (nearby) server.
--
Karl Vogel I don't speak for the USAF or my company
Teenage girl creates sustainable, renewable algae biofuel under her bed
--Extreme Tech headline, 19 March 2013
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171012204455.GA10740>