On Sat, Dec 06, 2014 at 03:35:10PM -0500, Paul wrote: > On Sat, Dec 6, 2014 at 11:12 AM, William Unruh <un...@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). -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
