[ntp:questions] Red Hat vote for chrony

William Unruh unruh at invalid.ca
Fri Dec 5 08:42:19 UTC 2014

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

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

> 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. 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. 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. 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.)

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

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

> Regards,

More information about the questions mailing list