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

Unruh unruh-spam at physics.ubc.ca
Thu Jan 24 23:08:29 UTC 2008


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

>Unruh,

>This answers my earlier question. I can't believe this is so crude and 
>dangerous. you really need to provide an analysis on the errors this 
>creates when reading the clock during the slew. The problem is not the 
>residual time offset but the rate at which time changes. Measuring time 

I am confused. The clock is off from the real time. Anything that happens
during the slew is less off than it was before. You are worried perhaps
that instead of 2 seconds having passed only 1 second and 700 msec have
passed?
Note that the rate change is also limited in chrony even during an offset
slew.

>intervals is very different during the slew. The NTP design carefully 
>limits this to no more than 5 microseconds per second without the kernel 
>and even smaller with the kernel.

OK, why?



>Dave

>Unruh wrote:

>> Brian Utterback <brian.utterback at sun.com> writes:
>> 
>> 
>>>Unruh wrote:
>>>
>>>>Just an update: I started chrony with a 60ms offset. It had the right drift
>>>>file. It took about 1 min ( having collected about 4 samples from the
>>>>servers at minpoll 4) to drive the offset down to about 100 usec (Yes, a
>>>>1000 fold improvement in about 50 sec.) Ie, the time constant for
>>>>correction of offset errors is enough time to collect enough samples to
>>>>determine that the offset really is statistically way off. 
>>>>
>> 
>> 
>>>Is that supposed to be impressive? One of the design constraints of NTP
>>>is to limit the clock frequency change during offset adjustments to
>>>500ppm to prevent NTP network instabilities. If the offset was
>>>amortized over the 50secs you stated, then that is a slew rate of
>>>1200 ppm. If this happened entirely at the end of the 4 samples, then it 
>>>sounds simply like a step to me. By that reasoning, ntpdate far
>> 
>> 
>> NO it is NOT a step. It is done via a fast slew by a change in the tick size, which can be 10% (ie
>> +-100000PPM) The clock always runs forward. It does not step. It may seem
>> like a step from the point of the coarse sampling done by chrony or ntp,
>> but if you ran a PPS clock and looked at the time returned by gettimeofday,
>> it would be continuous and positive, just like ntp. When the NPT offset
>> changes by 100ms between samples spaced at 500 sec apart, did it do that by
>> stepping? No it did it by increasing the frequency by 200PPM. Chrony
>> behaves the same way, only it uses the ticksize as well as the frequency to
>> produce fast slews to get rid of the offsets, and it does not go unstable
>> that I have ever seen. 
>>  
>> 
>> 
>>>outperforms chrony. I presume that chrony cannot behave as a server and
>>>only does clients right?
>> 
>> 
>> Chrony is also  a server. The key detraction for me is that it cannot use hardware clocks. 
>> It also does not act as a multicast/broadcast server  which may be a
>> detraction for others and does not do leap
>> seconds. On the other hand with its rapid response it will correct the
>> leapsecond within less than an hour. 
>> 
>> Anyway, the issue here is the clock disciplining routine, not a comparison
>> of the chronyd program with the ntp implimentation. 
>> 
>> I am arguing that chrony's clock discipline routine keeps the hardware
>> clock much closer to the real time (in the real world) and reacts to real
>> world changes much faster than does the NTP discipline routine. 
>> 
>> 
>> And chrony is just as stable it seems as NTP is. The offset fluctuations
>> are better than NTP's are. The key question is how close to the real time
>> is the time that the system clock delivers. Chrony is closer by factors of
>> at least 2 and probably if run at high priority as my ntp is, much better
>> than that. In particular if there are glitches in the clock drift rate,
>> chrony reacts much faster, and keeps the time much much closer to the true
>> time.  Instability would produce worse behaviour not better. 
>> 
>> 
>> 
>> 
>>>>I also started chrony without a drift file. In this case it took about 5
>>>>min to get a frequency within 10% of the long term stable frequency and
>>>>that "error" disappeared within 1/2 hour.
>>>>
>> 
>> 
>>>I don't know about the version of ntp you are running, but recent
>>>versions have a bug in the initial frequency calculations which
>>>has since been fixed, but not released (ahem. Harlan?).
>> 
>> 
>> The initial horrible  transient was under 4.2.0. After this round I will
>> try an initial transient test with 4.2.4.  But the transient
>> behaviour I am describing in the previous post is during the normal running
>>  of NTP. It is not  an initial transient. It is the response of the system
>> to a real world drift rate glitch.
>> 
>> It is after NTP has been running for 5 days and the hardware clock on the
>> machine suffered a frequency glitch. I have no idea what is causing those
>> frequency glitches-- the clock suddenly canges it drift rate by .2 to 2 PPM.
>> I have seen this both with a chrony controlled clock and an NTP controlled
>> clock. It is just that the NTP response is not good. 
>> 
>> 
>> 




More information about the questions mailing list