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

David Woolley david at ex.djwhome.demon.co.uk.invalid
Thu Jan 24 08:08:19 UTC 2008

Unruh wrote:
> I am sorry, but this is idiotic. The ONLY requirement should be that the
> communication protocol is implimented properly and that the clock is

Only a very small part of the mandatory parts of the NTP specification 
describe the wire formats.  The pool is an NTP network, not an SNTP one.

> 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

I believe they use techniques similar to those in ntpd and they are the 
people who come up with terms like Allan intercept.  However, they are 
operating with instrumentation where they know that the oscillator is 
the main source of error.  In the typical NTP setup, the clock is not 
responsible for the jitter component.

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

Actually, I believe the standard is an average of the individual clocks, 
  and has no physical hardware realization.  It is also only available a 
long time after the time to which it relates.

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

Dave Mills, if you are still reading, I would point out that to anyone 
reading this except for the committed ntpd users on this list (most of 
whom don't understand the clock discipline theory - I think I understand 
it better than many, but my understanding is still rather fuzzy - many 
have said that they don't understand and don't really care) will be 
pretty convinced that they should be using chrony for any real world 
clock synchronization.

Unless you address, on list:

- the problem that ntpd clearly reacts poorly to real world transients
   (and this is an issue that keeps getting raised, not just in this

- why chrony's algorithms are bad.

ntpd is going to lose the battle here for anyone reading the thread who 
wasn't already fundamentally committed to ntpd.

I don't have the depth of understanding to defend the ntpd approach and 
I agree with people when they say that ntpd fails to recognize and 
rapidly recover from situations where it is trivially obvious to a human 
that the time is wrong.

More information about the questions mailing list