[ntp:questions] Red Hat vote for chrony

Charles Swiger cswiger at mac.com
Fri Dec 5 14:37:37 UTC 2014

On Dec 5, 2014, at 3:42 AM, William Unruh <unruh at invalid.ca> wrote:
> On 2014-12-05, Charles Swiger <cswiger at mac.com> wrote:
>> On Dec 4, 2014, at 7:00 PM, William Unruh <unruh at invalid.ca> wrote:
>> [ ... ]
>>> Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
>>> done a lot of testing comparing chrony to ntpd ( which showed that
>>> chrony controlled the clock a factor of 2 to 20 times better than ntpd
>>> did), and is with Redhat. 
>> The data I've seen for chrony suggests it handles broken clocks such as
>> commonly found in VMs better than ntpd does.  The tradeoff is that
>> chrony prioritizes chasing the reference time over first trying to ensure
>> that the local clock frequency is stable, whereas ntpd really wants
>> to make sure that the local clock counts 3600 seconds in each hour of
>> wall-clock time and then worries about slewing the local time to match
>> up with the reference time.
> Nope. ntp changes the rate of the local clock to correct offsets. That
> is all it does. It does not make the rate correct, and then the offset.

If you don't know what the rate of the local clock is, how can you figure
out the proper slewing rate?

One can obviously keep slewing the clock towards the reference time even
without having a good idea of the intrinsic drift, but such an approach
will tend to overshoot the ideal frequency adjustment and "ring" or
oscillate back and forth.

> It simply alters the rate at any time so as to decrease the offset, and
> it does this measurement by measurement. It has no memory. 

This is obviously false.  What do you think /etc/ntp.drift is?

Furthermore, I distinctly recall you complaining that ntpd's clock filter
"throws away 7 out of 8 polls"; even though you are mis-interpreting the
situation, you at least acknowledged that ntpd is keeping track of prior

Or did someone else write Message-id: <Hh0tu.8666$tR7.4952 at fx22.iad>?

> Chrony uses the last N measurements to make the best estimate of the
> rate and the offset that it can. It sets the rate to the best estimate
> of the true rate, and then adds a rate correction to decrease the
> offset.

Yes, that's a reasonable approach.

>> It's informative to note that the chrony docs (section 5.3.4) recommend
>> using minpoll=2 and maxpoll=4!  With those settings chrony will send 225
> that is for refclocks. 
>> polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10.
>> Assuming arguendo the claim of "a factor of 20 times better" is true, I
>> still don't care to pay the price of a factor of 64 times more network polls.
> You may set the minpoll and maxpoll to whateever you want. But chrony
> does not advocate a maxpoll of 4 over the network. Read again. 

I suggest following your own advice before trying to correct others.


"5.3.4 How can I improve the accuracy of the system clock with NTP sources?

Select NTP servers that are well synchronised, stable and close to your network. It’s better to use more than one server, three or four is usually recommended as the minimum, so chronyd can detect falsetickers and combine measurements from multiple sources.
[ ... ]
The optimal polling interval depends on many factors, this includes the ratio between the wander of the clock and the network jitter (sometimes expressed in NTP documents as the Allan intercept), the temperature sensitivity of the crystal oscillator and the maximum rate of change of the temperature. An example of the directive for a server located in the same LAN could be
server ntp.local minpoll 2 maxpoll 4 polltarget 30"

The docs aren't talking about reference clocks here, they are talking about
polling another machine over the LAN.

>> Furthermore-- unfortunately-- I have yet to see data on the accuracy of
>> chrony measured against high-quality TCXO or Rb/Cs reference clocks,
>> such as the PRS-10 that PHK used:
>> http://www.thinksrs.com/products/PRS10.htm
>> ...the current version of which claims to have a +/- 10 ns accuracy for
>> the PPS signal.  Instead, most of the data I've seen provided for chrony
>> has involved comparing local clock timestamps to the reference timesource
>> or to some other network timesource, without detailed information as to the
>> accuracy of those references.
> Nope. I have done measurements on the net where I compared the net to a
> gps PPS source. The computer PPS has an accuracy of about 1microsec and
> that can be compared to the network time.

About a microsecond is two orders of magnitude worse than ~10 nanoseconds.
As I said before, I'd be happy to review data for chrony taken against that
quality of reference.

> I get an increase of about 2-3
> times better than ntp. Lichvar got something like 20 times better using
> a PPS against a local high accuracy time source. The main reason seems
> to be that chrony is far more algile-- it catches temperature drifts
> much more quickly than ntpd does, for the same poll.

More agile is almost always less stable.  I'd rather my timekeeping software
figure out the average intrinsic drift averaged over long time intervals
such that it keeps an average frequency correction rather than chasing
short-lived drifts due to thermals.  But then, I also make sure that my
timeservers are running in temperature-controlled environments so that
such daily drifts you mention are minimized.

> Remember that ntpd
> throws out 85% of the measurements it makes, in order to try (poorly) to
> compensate for network up-down inequalities. Sometimes, if the network
> is very variably assymetric that can improve results. Usually it simply
> throws away valuable measurements.

Ah, I thought this claim would reappear.  Note that you're contradicting
your earlier claim that ntpd doesn't remember anything before the last poll.

> ntpd is also designed to act very
> slowly to changes in rate. It is a design philosophy Mills defends
> strongly, with the matra of stability.


> Chrony, because of its long term
> memory, recognizes and responds to rate variations much more quickly,
> with no sign of instability. It would be good to have a detailed
> analysis of the chrony algorithm to see if there are corner cases where
> chrony does worse by going unstable. ntpd is simple to analyse (if one
> ignores the extreme non-linearity of the "jump" if the offset is greater
> than 128ms.)

Also agreed.  It will be interesting to see whether chrony starts including
more sanity checking after being exposed to a wider range of use-cases
from Red Hat's adoption.

> If you would like to compare chrony vs ntp with your PRS10, please do
> so. Otherwise look at some of he numbers I have on
> www.theory.physics.ubc.ca/chrony

Lots of RRD graphs; no signs of measurements taken against a sub-microsecond
reference, though.

>> Of course you're not going to see much delta between the local clock and the
>> reference that you're polling every 16 seconds.  Without measuring the
>> local clock against some other clock or oscillator which is known to be
>> accurate to sub-microsecond levels, one doesn't have the data needed to draw
>> conclusions about the actual timekeeping precision.
> Actually not true.

What isn't true?

> How do you think the standards of the various
> contries determine the accuracy of their clocks. They have no better
> time standard to compare them with. And yet they confidently will quote
> accuracy figures for their clocks. Study that.

For almost all of human history, the sun or the "fixed celestial heavens"
have provided the most accurate time reference available.  Even today,
we add (or subtract, in theory) leap seconds in order to keep UTC and UT1
aligned to better than a second courtesy of IERS.

Yes, the USNO, CERN, and so forth now do have sufficiently high quality
atomic clocks which have better timekeeping precision than celestial

Such a point is orthogonal to the notion of how to measure a local clock,
unless of course one is using those high-quality atomic clocks as the
reference to measure your local clock against.


More information about the questions mailing list