[ntp:questions] Test internal clock

Unruh unruh-spam at physics.ubc.ca
Fri Mar 20 17:00:51 UTC 2009


hundoj at comcast.net (Rob Neal) writes:

>On Fri, 20 Mar 2009, Unruh wrote:

>> hundoj at comcast.net (Rob Neal) writes:
>>
>>>>
>>>> It almost seems like a religious group.  Most people try to convert
>>>> the world to Mills' NTPD, and then there is the dissident who tries
>>>> to push Chrony in every thread.
>>> 	Chrony has an impulse response that is ill-advised in
>>> 	a network of NTP servers. It's really rather crude, IMHO.
>>
>> An interesting claim. What is it about the chrony impulse response that you
>> do not like and why is it "ill-advised" in a network of ntp servers? I
>> really am interested in the answer. I would think it is far less crude than
>> is ntpd, but would love to understand your reasons.
> 	The slew rate. NTP limits the slew rate to 500 PPM,
> 	for purposes of error bound analysis and conformance
> 	to common software constraints. It is, in the end,
> 	a PLL.

> 	Chrony does not appear to have either such analysis
> 	of errors, nor a bound on the slew rate.
> 	If you have no bound on the slew rate, then
> 	you cannot make mathematical statements about
>    	the response to transient inputs - such as the time
> 	to amortize an offset.
> 	If one cannot bound, via mathematics, the transient
> 	response, then how can one constrain the loop
> 	stability?
> 	And if one cannot bound or define the loop stability,
> 	then its use in a large network of like performers
> 	becomes problematic. How does one bound the
> 	oscillation between partners, under these conditions?

> 	It may be that these questions have practical answers,
> 	disjunct from the analysis, that are perfectly adequate
> 	in practice. I have seen no such demonstration, so I
> 	prefer the bounds within NTP. These have been supported
> 	by extensive analysis, and practical deployment.
> 	Perhaps not perfect for all purposes, but usable.

> 	I would expect that for leaf nodes, Chrony would be
> 	a totally acceptable solution, with characteristics
> 	that would make it attractive to a large number of
> 	system administrators.

> 	Does this answer address your concerns?

> 	Regards,
> 	Rob


Thank you. It certainly explains your thinking. I do not believe it is a
problem, but I have been trying to squeeze in such an analysis of chrony.
First, I think getting some sort of refclock support into chrony, even if
just shm is a more important step, and have not found the time for it. When
one is changing a program written by someone else, there is a lot of
puzzling one has to do before making changes.


NOte that ntp will far more often hit the 500PPM bound than does chrony
because of its very poor (Ie, slow) transient response to
rate transients. Chrony can go above 500PPM for large  offset transients, but offset transients
are rare because the temperature affects the rate not the offset. (Also for
large offset transients >128ms, ntp goes to an infinite rate model. It simply
resets the clock, or stops altogether, a far more drastic behaviour than
chrony ever displays).
The response to multiple servers and jumping between them is an interesting
question.





More information about the questions mailing list