[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Unruh unruh-spam at physics.ubc.ca
Mon Jan 21 22:07:06 UTC 2008


david at ex.djwhome.demon.co.uk.invalid (David Woolley) writes:

>In article <XP4lj.15282$yQ1.8066 at edtnps89>,
>Bill Unruh <unruh at physics.ubc.ca> wrote:

>> Offset error:
>>    NTP: Mean=-3.1usec, Std Dev=63.1usec

>If offset is the value reported by ntpq, please note that, when ntpd
>is locked up, this is an indication of the instantaneous measurement
>error, the actual error in the local time should be more stable (there may
>be systematic error) by one or two orders of magnitude.

No, the offset is the value reported in loopstats.


>More generally though, Dave Mills really needs to get in here and defend
>his clock discipline algorithm, and the Chrony developer needs to 
>defend theirs.  Arguing the cases by proxy isn't particularly satisfactory.

This is not arguing by proxy, this is running experiments. As I know, since
I am a physicist, experiment trumps theory always. 



>Dave, please remember that what tends to concern people about the algorithm
>is not the behaviour in response to gaussian phase noise, but its behaviour
>in response to transients, in particular startup transients.  (Personally
>I would say that lost clock tick transients should be fixed at source,
>but Bill Unruh would also like it to tolerate those well.)

>>   Chrony: Mean=-1.5 usec, Std Dev=20.1usec

>Given the way that I understand it works, I think this is the actual
>correction applied on that sample.

No, this is offset as measured by the ntp procedure ( (t1+t4-t2-t3)/2 )




>> Rate fluctuation:
>>   NTP:Mean=25.32  Std Dev=.078 (PPM) 
>>   Chrony: Mean=25.26 Std Dev=.091 (PPM)

Running it for a longer time, the standard deviation of the rate for ntp
has dropped to about .020PPM, which is much better than chrony's. 



>The means depend on the hardware, and, as long as they are within the order
>of one standard deviation of each other, they are as good as each other.

Yes, I agree that the mean rates are the same. It is the standard deviation
that is important here. Ie, ntp seems to be much "better" (smaller
fluctutation) than chrony here, at the expense of much worst offset control
(which makes sense if the rate fluctuations are real-- ie, I can make
chrony's rate fluctuations much smaller by i running averaging the rates over a
couple of hours but that will make the offset deviation increase. I guess
it depends on which you consider more important, and accurate rate, or an
accurate clock.



>From the point of view of another machine, chrony will have episodes where
>the frequency changes much more, as it applies the phase correction.

??? These are done on the same machine. If you mean that the real drift
rate of the computer changes, then chrony's rate will change, then I would
hope that that happens. Remember that this is not comparing two different
machines, but the same machine at two different times. 

And yes, the physical events could have changed between the two. It would
be nice if one could do a simulation-- put them both on some virtual
machine and feed in exactly the same real clock drift changes, and use some
model of the noise ( measurement, transmission, etc) so one could provide
the two algorithms with exactly the same data to work with. But neither
chrony nor ntp are set up for that. 



>> over the weekend, and chrony encompassed the weekdays when the grad
>> students use the computer) the offset control by chrony was a factor of 3
>> better than by ntp.  

>If the figures are the actual correction for chrony and the sample error for
>ntpd and Dave Mills is correct about the phase noise rejection of the ntpd 
>filter being a couple of orders of magnitude, ntpd might actually be 30 
>times better.

Nope, the figures are the actual samples as measured by chrony, and the
"processed" output from ntp as reported in loopstats-- whatever that figure
is. Ie, if processing makes a difference then the advantage lies with ntp.
But I just checked  using the offset reported in peerstats (choosing only the packets from the  one local server)
 I get the same result as from loopstats. 
Ie, both  the results for ntp and for chrony are the raw offsets. 
and chrony's are about 2.2 times better than ntp's.

So, chrony, at least in this one test, controls the offsets of the clock
much better, at the expense of worse consistancy in the frequency. It also reacts
much faster to gross changes in the time ( eg startup with no drift file).









More information about the questions mailing list