[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
unruh-spam at physics.ubc.ca
Wed Jan 23 20:51:53 UTC 2008
Brian Utterback <brian.utterback at sun.com> writes:
>> 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