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

Danny Mayer mayer at ntp.isc.org
Thu Jan 24 13:28:51 UTC 2008

Unruh wrote:
> 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
> compliant). 

I agree. I don't see how it can be a specification violation. The 
biggest factor is how well it keeps time. A caesium clock keeps good 
time but you wouldn't say that it violates the specification.

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

While the NTPv4 draft does discuss the difference between SNTP and NTP 
it is not as clear as it might be. It might be a good idea to clarify this.

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

The quality of the packets should be what counts here rather than the 
specific implementation and I have seen nothing here that indicates that 
chrony is not a good candidate for the pool. The last discussion on 
openntp indicated that there were many issues with it but we don't know 
what has changed since then. For the pool, being able to query the 
server is important to review the quality of each packet but to my 
knowledge only ntpd has implemented the query capability. That should 
not stop an implementation being a good candidate for the pool.

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

Well there are plenty of situations where a very accurate clock is 
*very* important and rdate and company are not good enough. I will tell 
you that Dave is never satisfied with his own algorithms and is 
constantly reworking them to have them work better over a very wide 
range of conditions. Like everything else there are compromises that 
must be made in order that the best results are obtained over such a 
wide range of conditions. I don't think I have ever seen a document 
which enumerates and discusses all of those conditions though it 
certainly does exist inside Dave's head.


More information about the questions mailing list