[ntp:questions] Red Hat vote for chrony

Charles Swiger cswiger at mac.com
Sat Dec 6 12:27:22 UTC 2014

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.

You setup a high quality clock somewhere and pull timestamps from the
general purpose computer you want to measure.  Something like Nagios
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.

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


More information about the questions mailing list