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

Unruh unruh-spam at physics.ubc.ca
Thu Jan 24 03:13:15 UTC 2008

David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> Chrony is also  a server. The key detraction for me is that it cannot use hardware clocks. 

>That would be a specification violation (should level, I think), as 
>chrony is only an SNTP implementation.  In some "off list" 
>correspondence with Dave Mills be points out one reason for this is that 
>the end to end response of an NTP network depends on all steps 
>implementing the protocol properly.  My impression is that, even though 
>the clock discipline algorithm isn't normative in NTPv3, that includes 
>using the specified discipline algorithm.  I suspect this may be 
>enforced in the latest version of the specification.

I am sorry, but this is idiotic. The ONLY requirement should be that the
communication protocol is implimented properly and that the clock is
disciplined properly. Anything else is none of the network's business ( and
furthermore they have no way of knowing--  the packets are fully ntp

I have no idea what you mean that it is only an SNTP implimentation. 
Chrony does nothing to upset the end to end response of the network. 

>I strongly suspect that the pool server people wouldn't want chroony as 
>a pool server, although it turns out that someone was running optenntpd 
>as one.

They have no idea unless I tell them.  And if it actually disciplines the
clock better, then they would be idiots if they took that attitude. Of
course convincing that it actually does discipline it better might be the

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

>You cannot say that except when the system is clearly out of lock, as 
>you are not measuring the necessary parameter, because to do so would 
>require special instrumentation.

Yes, I can say that. Elementary clock measurement techniques tell you which
of the two clocks is better, even if you do not know which. How in the
world do you think the people who run the national time standards know
which the better or worse clocks are? They have no clock that is better
than the ones they have to act as a standard. They have the best in the world,
 and they can tell which is better or worse. 

If A and B both using the same time standard C 
 and if A compared to C has much less variance than B when compared with C, then A is
better. You do not know exactly how much better, but you know it is better.
( C does not have to be better than A and B, just not much
worse. But in my case, string (C)  is much better ( NTP controlled by ai GPS PPS)
than A (flory on chrony) or B(flory on ntp).)

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

>As noted in another article, I suspect what might be needed is a mixed 
>approach, using the chrony approach to gain or regain lock (whilst 
>signalling alarm and stratum 16 downstream) with the ntpd approach used 
>when the loop is locked.  However Dave Mills can be particularly stubborn.

I have no idea why a mixed strategy is needed. Even in steady state, chrony
does at least as well as, if not significantly better than NTP. 

Stubborness is good. As long as it is allied with a willingness to listen
and reexamine his own preconceptions. Scientific progress is made by people
defending their position but being willing to give it up if it becomes
clear that it is wrong. 

I am not arguing that chrony's approach is the be all and end all. I think
that there are problems. One of the reason I did the comparison was to see
if ntp did things better. I see "oscillations" with chrony, but I am not
sure if they are real ( ie correspond to real variations in the drift rate
of the clock) or are somehow generated by chrony. The oscillations in the
frequency seem to be less in ntp but the offsets worse. You can of course make the changes
in the frequency zero, by never changing it. That will of course make the
offsets attrocious. That tradeoff may be what is happening with NTP. 

But, so far the evidence is that chrony does better on almost all fronts
than ntp does as a clock control mechanism, whether on transients or in
steady state. 

Of course I have only tested things in a limited range of situations. 
If there are areas where it is worse, I would be anxious to find out what
they are. 

The purpose of ntp is not to be a monument to Dave Mills. It is to get the best
control of computer clocks on the network possible. I am positive that he
agrees with that. Then the question is how to do that. That is what I am
trying to investigate. 

Note that the attitude might be "who gives a damn. NTP computer clock
control is better than anyone has need of anyway." That is of course an
impregnable argument. It was also an argument that I am sure came up when
Dave developed ntp. rdate even now is pleanty good enough for almost all

More information about the questions mailing list