[ntp:questions] Red Hat vote for chrony
mlichvar at redhat.com
Mon Dec 8 13:45:36 UTC 2014
On Sat, Dec 06, 2014 at 03:35:10PM -0500, Paul wrote:
> On Sat, Dec 6, 2014 at 11:12 AM, William Unruh <unruh at invalid.ca> wrote:
> > 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.
> I looked at your data back in the day. Even then I thought they were old.
> Of course if the secret sauce is loop constants (I haven't read the Chrony
> architecture document, maybe because there isn't one) then perhaps the
> results would still be the same.
The main part of the "secret sauce" is the variable number of points
used in the linear regression. When the clock frequency changes
quickly, only a small number of points will be used to get a better
estimate of the current frequency offset. I.e. chronyd adapts to
the Allan intercept without changing the polling interval. This
adaptation doesn't always work perfectly, the current code often
reduces the number of points unnecessarily, but there are some ideas
that will likely be implemented in the future to improve it.
Of course, a similar approach could be used with the NTP PLL/FLL loop.
If the time constant wasn't fixed to the polling interval and the FLL
part of the loop wasn't active only when the update interval is longer
than 2048 seconds, the performance could be improved significantly. I
was suggesting this years ago.
It would be nice if there was at least a tinker option to shift the
constant as needed, but a patch for that was rejected. So now the
Linux kernel uses a nonstandard PLL shift to get a better performance
with ntpd and current typical network jitters.
If you like the slow response of ntpd, chronyd can be configured with
the minsamples and maxsamples options to use a fixed number of points
and to some extent imitate ntpd. In my testing, when the number was
set to 40 the overall time and frequency errors were quite close to
ntpd (running on Linux).
More information about the questions