Re: [gpsd-dev] Final revisions to the Time Service HOWTO

[Miroslav Lichvar]

On Wed, Nov 20, 2013 at 12:37:19AM -0500, Eric S. Raymond wrote:
> I'm walking through the process in the HOWTO.  Some questions that are
> coming up:
> 
> 1. ntpd versus chronyd.  What criteria suggest one, what the other?
>    What should the HOWTO say about the tradeoffs?  Even if it's as
>    simple as "chrony fans like it because X" and "ntpd fans like it
>    because Y", we need to say *something* to explain why both
>    exist and help the reader make an informed choice.

I think this is mostly covered in the CHRONY-COMPARE link. The
original reason chronyd was written was that ntpd didn't work well
with dial-up internet available only for few minutes a day. Other
reasons to prefer chronyd over ntpd could include better accuracy,
faster synchronization, smaller footprint (important on embedded
devices) or support for tracking of the RTC drift to allow starting
with reasonably accurate time even when no other time sources are
available.

Reasons to prefer ntpd over chronyd could include missing support for
non-Linux systems, NTPv4 and Autokey authentication.

Some comments on the current version of the text:
> Of these two, ntpd is the older and more popular choice - thus, the
> one with the best-established peer community if you need help in
> unusual situations.  On the other hand, chrony has a reputation for
> being easier to set up and configure, and is better in situations
> where your machine has to be disconnected from the Internet for long
> enough periods of time for the clock to drift significantly.

I mentioned it before, I don't think chronyd is easier to set up or
configure. As the text is focused on using chronyd with a reference
clock, the paragraph could say "where your GPS is not available for
long enough..." instead.

> ntpd and chrony have differing philosophies, with ntpd more interested
> in deriving conensus time from multiple sources while chrony tries to
> identify a single best source and track it closely.

Yes, the default chronyd configuration is focused on best time
accuracy. Recent versions combine multiple sources too and it can be
configured to not track the source as closely if you want to improve
the overall frequency accuracy of the clock. There is always a
tradeoff between time and frequency accuracy.

> gpsd can provide reference clock information to chronyd similarly to
> the way it talks to ntpd.  The advantage to using chrony is that the
> PPS time resolution is in nanoseconds.  This is 1,000 times more
> precision than the microsecond time resolution provided to ntpd.  This
> only matters if you has an RS-232 connected 1PPS refclock.  When
> gpsd supports the new ntpd protocol this difference will disappear.

This is no longer true as the nanosecond SHM support was added to
gpsd.

> Typical specs for oscillator packages are 20, 50, 100 ppm.  That includes
> everything; initial accuracy, temperature, supply voltage, aging, etc.

Please note that the most commonly used clocksource in current systems
is the time stamp counter (TSC) in the CPU.

> Note that a low drift contributes to stability, not necessarily accuracy.

I'm not sure I understand this part. When a clock has 100ppm drift, it
doesn't mean it's not stable, or not?

> So how do we calculate the drift?  The general idea is simple.  Measure the
> time offset every N seconds, plot the graph, and fit a straight line.  The
> slope of that line is the drift.  The units cancel out.  Parts-per-million is
> a handy scale.

I think ntpd uses linear fit only on start without driftfile to get an
initial frequency. In normal operation it works just with the latest
measurement. The clock is adjusted by a PLL/FLL hybrid loop. The
polling interval sets the PLL time constant, the ratio between them is
fixed and may differ between systems (Linux uses 4 times shorter time
constant than the reference design). If the clock is behind, the
frequency will be increased a bit, if it's ahead the frequency is
decreased. If the initial drift is wrong or the frequency changes
rapidly, it may need a large number of updates until it settles down.

> //FIXME: Is it correct that chrony uses a linear fit with low-pass filter?

Yes, it uses up to 64 past measurements to make the fit. The measured
time and frequency offsets are corrected separately. The number of
points in the fit is selected by a statistical test.

> ntpd and chrony automatically adjust the value of the polling interval
> to get the best results.  That turns into the N above.

ntpd controls the polling interval which sets the time constant.
chronyd controls the polling interval and separately also the number
of points in the linear fit.

With reference clocks, however, the polling interval in ntpd is fixed
by default to 64 seconds (minpoll 6 maxpoll 6) and chronyd uses always
constant polling interval, 16 seconds by default (poll 4).

> //FIXME: Is this description correct of chrony?

Seems ok.

> //FIXME: What more can we say about chronyd tuning?

There could be a paragraph about setting polling interval, but it's
not as important as with ntpd. Shorter interval allows faster reaction
to changes in frequency, but may worsen the stability (e.g. when it
would be needed to use more than 64 samples).

-- 
Miroslav Lichvar