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

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


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

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

It does not matter what the source of the variance is. If A has smaller
variance when hooked up to C than B, then A is a "better" clock, no matter
what the source of noise is. 



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

>- 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 doubt that actually. ntp has by far the biggest set of people.


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


I just ran a case where I purposely glitched an ntp clock ( the very latest
stable release of ntp 4.2.4p4)-- after it had settled down 
down from its initial transients-- by 40 ms. ( adjtimex -t 10100 for about
6 sec) to see what its reaction would be. The offset was 40ms, the rate
rapidly went to -14ppm from -6.5, the offset dropped through zero after
about half an hour, overshot to about +8 msec, and that is gradually
decaying to zero. The rate is coming down but after about 2 hours is still
at -8PPM (rather than 6.5) 

Look ntp is great. It is amazing that we can control clocks on a local
network to 50usec and over 2000miles to msec. The question is what is the
best way of discipling the clock. the ntp algorithm is relatively simple.
The chrony one is much more complex. chrony also is primarily a linux
thing. However, I want to know what the best way of disciplining the clock
is. Just what are the limits to our ability to discipline a clock over the
network.







More information about the questions mailing list