chrony as default NTP client?

[Gregory Maxwell]

On Sun, May 9, 2010 at 4:15 PM, Ryan Rix <ry at n.rix.si> wrote:
> Here is how I see this: The user installs their system for the first time,
> they set their clock using NTP while they have the connection to the
> internet when they installed their packageset/updates. Now they have an
> accurate clock.
>
> How much drift can happen that each and every time they connect to the
> internet, even if it's only for five minutes, would they need to resync
> their clock? I have NTP disabled altogether on this machine, and since
> I've installed it, it's still within about 5 seconds of my mother's
> Windows machine which _does_ have ntp disabled.

The amount of drift you may see is highly dependant on your hardware.
A mere 1% frequency offset will gain or lose almost two hours per week.

Arguably a system which drifts unacceptably is broken yet depending on
your definition of unacceptably all of the available PC hardware is
broken.  And a constant frequency offset like that is trivially
fixable.

My last laptop lost a minute or two per week of uncorrected operation.
At the time I was travelling a lot— and ending up habitually a late
for a conference calls would remind me to unwedge it.  The current
laptop has, fortunately, only lost 2 seconds since Friday.  Two
headless systems of mine with "good" clocks in a temperature
controlled environment show drift of 16 and 37 ppm (0.7 and 1.6
minutes per month respectively).

A typical decent crystal oscillator simply running 10 deg C off its
design temperature might be ~20 ppm off on its own.

> I find that having NTP enabled in most cases for mobile systems is simply
> unnecessary; there is a large (I would say upwards of 95% in my most
> unscientific guessings) chance that these users aren't going to be doing
> anything which requires their clocks to be synced with any amount of
> precision. And if they are, they should _know_ that and be able to set up
> a tool (whether it is NTP or Crony) themselves.
>
> Imo the use cases for having a constantly synced-to-the-second clock are
> minimal at best.

"I find that having non-root accounts enabled in most cases for mobile
systems is simply unnecessary"(...)

But really— having accurate time is important for all systems: Have
you never had the experience of trying to debug a networked system
only to eventually discover that there was a few seconds clock skew
confusing your troubleshooting?

At least in my world there are increasingly only two kinds of
machines: mobile devices and headless servers, in that context what
you're saying is that only servers need correct time, and I think that
is quite wrong.  Errors at the level of minutes are easily accumulated
on common hardware and will impact human affairs.  Sub-minute errors
will frustrate technical troubleshooting— confusing the mutual
ordering of events between systems even when the timestamps look quite
different.

An inaccurate clock even reduces user privacy on the internet as it
makes hosts more easily distinguishable when the client's time is
available over the network.

If timekeeping really hard to fix on the lossy hardware we use I might
buy an argument that fixing it wasn't worth the cost, but fortunately
it is easily fixed to sub-second levels by running a simple daemon.
Though, unfortunately, the NTP package will often fail to do anything
useful when used on the increasingly common configurations with highly
intermittent network connectivity.

Perhaps you may not care about these things— but other people do for
good reason, and you ought not oppose their efforts to advance the
usefulness of the system.