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

Unruh unruh-spam at physics.ubc.ca
Thu Jan 24 19:24:54 UTC 2008


"Maarten Wiltink" <maarten at kittensandcats.net> writes:

>"Unruh" <unruh-spam at physics.ubc.ca> wrote in message
>news:KRXlj.27807$yQ1.16375 at edtnps89...
>> "David J Taylor"
><david-taylor at blueyonder.neither-this-bit.nor-this-bit.co.uk> writes:

>>> chrony falls at the first hurdle for me - there appears to be no native
>>> Windows implementation.
>>
>> Correct. chrony is not implimented on nearly as many platforms as ntp.
>>
>> There were plans once upon a time, but life got in Curnoe's way.
>> Anyway, I am NOT advocating everyone change to chrony. I am trying to
>> understand the clock discipline algorithm. It uses a lot of the special
>> features of linux.

>And that is _not_ a good thing. To win over the world, as the other David
>(Woolley) predicts elsewhere, it would need to be available on Windows at
>least. That might actually happen. But to win over some of the people who

Sure, it would be nice. It sure will not be me. HOwever if people are
convinced that chrony is a better approach ( and that still does need
proof, even though the suggestions are there) then I am sure volunteers
will be found to port it to Windows.  That is after all how NTP got ported. 

>_really_ matter, it would have to be implemented in a simple, transparent,
>and platform-neutral way, and to be driven by clock engineering, not code
>writing. The other other David (the original Dave) can *prove* that NTP

It is, and this discussion and my experiments are precisely to try to do
the clock experiments to see which approach works better. I think Curnoe
did put a lot of effort into thinking about how to make it work when he
wrote chrony some 10 years ago-- astonishingly it has changed very little
and still works extremely well. 


>will not go unstable under a variety of adverse conditions. Curnoe may
>have years of logs showing that chrony keeps offsets lower than ntpd, but
>standards laboratories are likely to shrug that off as anecdotal evidence,
>not proof.

Well, no I do not think he does.  I suspect I have the most logs of anyone in the world
(www.theory.physics.ubc.ca/chrony/chrony.html-- follow the past logs link)


>And anybody who's really serious about timekeeping seems to be playing with
>reference clocks on FreeBSD. Err...

OK, I do not know why, but... 
Anyway, I think chrony works on BSD, but could not swear to it. It does
work on SunOS and Solaris ( or did) but they have (had?) terrible clock
control -- no frequency changes-- at least as implimented in chrony.
chrony is old code, but it works very well. Its whole design goal is to
reduce errors in the offset. It is really hard to go unstable if that is
the goal, but it is possible, especially if you are interested in very long
intervals between clock queries. It is at that point that you want to make
sure that your model of the frequency drift and your estimation of the
frequencies is the best possible. I do worry a bit about chrony in that
situation, but have no reasons for that worry. The very worst case is if
the system runs for a while on very short poll intervals, and then suddenly
has very log poll intervals. The short period estimation of the drift is
not a good estimator of the long period drift. But I suspect that NTP would
have problemsi in that situation as well. 








More information about the questions mailing list