Another 11.1-RELEASE install minor annoyance (ntpd)

[Karl Vogel]

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 at 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