[ntp:questions] Red Hat vote for chrony

William Unruh unruh at invalid.ca
Sat Dec 6 16:12:25 UTC 2014

On 2014-12-06, Charles Swiger <cswiger at mac.com> wrote:
> On Dec 5, 2014, at 5:01 PM, Paul <tik-tok at bodosom.net> wrote:
>> On Fri, Dec 5, 2014 at 7:06 PM, Charles Swiger <cswiger at mac.com> wrote:
>>> No, he used a $1500 rubidium clock to accurately measure the timekeeping
>>> quality of a $220 Soekris computer, and concluded:
>>> "The data on this page was obtained using a setup which was designed to eliminate all sources of errors and only measure the ability of the Elan CPU to timestamp an external signal."
>>> "The timestamping is done using the internal general purpose counters which get their input from the system clock crystal input. Normally this is connected to a 33.3 MHz quartz crystal, but to eliminate the temperature dependency of the clock, a 33.33333... MHz signal derived using a ICS 521 PLL chip, which again gets its input from a SRS PRS10 Rubidium frequency standard"
>>  Not that it matters but I read this as -- if you don't replace the clock you have other sources of error.
> Um, certainly?  Are you concerned about the quality of the XO which shipped with a Soekris board?
> That'd be important if you were running a stratum-2+ timeserver.  
> On the other hand, setting up a stratum-1 using an attached GPS w/ PPS
> would bump the total price up to ~$260, and you'd be limited only by the
> quality of the GPS clock itself (ie, ~microseconds) via kernel PPS discipline.
>> Here's a more detailed look: <http://www.febo.com/pages/soekris/>
>> But to try and stay on point:  how do you measure the performance of a typical disciplined "system" (virtual) clock in a general purpose computer -- ideally without specialized hardware and software but those are okay if the results can be meaningfully generalized.  Given those measures you can decide if you prefer NTP, Chrony, SNTP or something else.

And in my tests 10 years ago or so, I used a local gps clock to test the
ability of chrony and ntpd to discipline a computer clock networked to
another server which was disciplined by a gps. Thus the network was the
same, and the difference was ntpd vs chrony.
chrony was better. Primarily, I think, because chrony responded more
quickly to drift rate changes due to temp changes. 

> You setup a high quality clock somewhere and pull timestamps from the
> general purpose computer you want to measure.  Something like Nagios

You run on the computer itself, so that network propagation noise does
not add to the clock noise. 

Certainly if you have a better clock you can use it to measure a poorer
clock. But as I pointed out, all of the standards bodies know what the
noise performance is of their clocks without using any better clocks--
they have the best clocks in the world. And yet they manage.

> or other network monitoring tools will measure and chart time offsets
> using NTP queries over the LAN for entire fleets of machines or VMs,
> and generate alerts if a clock goes out of sync.


> That should be accurate to millisecond level of precision or so, limited
> mostly by your local network conditions.

Actually tens of microseconds for a local network. 
>> By the way --
>> Some folks will be satisfied with Miroslav Lichvar's simulations but I'm not smart enough to understand them.  Other's will be convinced because they can run Chrony on a Unix laptop and save power or discipline a clock with only a few minutes a day of connect time.  I don't know who those people are.

> Sure, those seem to have been the major use-cases that chrony wanted to handle.

You do not understand them, but feel confident to make recommendations
despite that? The main reason for using chrony is that it disciplines
the clocks better than ntpd does, in many cases. Whether there are
cases where it does more poorly I do not know. But why would you
castigate a distro for using a better tool? 
Note that it also has a greater tolerance for going off line as you say.
(No idea what the "save power" line is all about. Both chrony and ntpd
send out the same packets and both have roughly the same polls, so where
is this "powersaving" coming from?) 

Anyway, run your own tests, decide for yourself.

> Regards,

More information about the questions mailing list