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

David L. Mills mills at udel.edu
Fri Jan 25 21:53:51 UTC 2008


The 500 PPM limit in the reference implementation was originally set to 
match the adjtime() slew of that value, but so many kernels have been 
hacked adjtime that this might not even be appropriate now. The bottom 
line is that an update given to adjtime() should be completed before the 
next update. Even if it's not, the leftover is carried over to the next 
update. However, in order to avoid disturbing application programs that 
compute intervals, the slew rate should be no more than necessary.


Brian Utterback wrote:
> Danny, I agree with everything you said except:
> Danny Mayer wrote:
>> 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.
> When we first started looking at the V4 spec for the ntp-wg, my first
> thought was the same as yours, namely that what happens inside a system
> shouldn't matter, the algorithms don't matter, only what it chimes
> matters. And strictly speaking, this is true. However, after reading
> Dave's book (Das Buch as he calls it), I realized that an important
> factor to the stability of the NTP network is the actual speed at
> which the clocks slew, i.e. the 500 PPM limit. This is largely
> ignored in the spec. I sent in some comments about how I thought it
> should be addressed but alas, my changes didn't make it in the latest
> versions.
> Brian Utterback

More information about the questions mailing list