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

Unruh unruh-spam at physics.ubc.ca
Tue Jan 22 18:24:40 UTC 2008


"David L. Mills" <mills at udel.edu> writes:

>Unruh,

>It may help to review the material on Allan deviation and noise 
>modelling in the briefings on the NTP project page. If you are down in 
>the low microsecond range with poll intervals much over 64 s, expect to 
>see a frequency sway due to small temperature variations less than one 
>degree C. This should appear random-walk in nature and not periodic. Be 
>hortunate about the temperature dependency; it makes a very good fire 
>detector and fan failure alarm.

Sure, I understand that. I am not worried about the fluctuations in the
frequency, especially if they track real fluctuations in the drift rate of
the clock. I am worried about the offsets, since they indicate that the
system is NOT following the real drift rate of the clock. Especially when
the fluctuations are highly correlated ( ie are not just random noise).

The much better behaviour of chrony on offsets suggests that ntp is NOT
following the drift rate of the clock. Especially as the scatter on chrony
is a) much more random and b) I suspect is tied to the much worse behaviour
of chrony in the round trip time department. Ie, chrony is doing much
better (in controlling offsets)  even though it is suffering much worse noise than is ntp.



>Dave

>Unruh wrote:
>> 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