On 06/12/14 16:33, William Unruh wrote:
memory. And in normal operation, it does not even know about the current drift rate-- it is the operating system that does that. All ntpd does is
That's because part of the NTP algorithm is implemented in the kernel where it can be done per tick with negligble overhead.
to change the current drift rate to try to minimize the offset.
It, or the NTP code in the kernel, maintains two separate corrections, one for short term phase errors and one for long term frequency errors.
IF the operating system is incapable of changing the clock rate, ntpd tries to do it for the operating system. Every second it resets the clock to take into account the error in the rate of the clock. In this case, ntpd remembers the current drift rate. But only the current drift rate. Again, it has no memory of the past.
The very long time constant means that it remembers many hours into the past when operating at the longest poll interval. In fact your real complaint is not that it doesn't use historical data, but that it looks too far back in history.
If I read https://www.eecis.udel.edu/~mills/ntp/html/discipline.html correctly, and allowing for "times" really meaning "plus", the frequency control time constant is 2048 seconds (34 minutes) for poll=6 and about 9 hours for poll 10.
As noted in that paper, there are two correction terms, a relatively fast one to correct the phase, and the one discussed above to correct the long term frequency.
I suspect that chrony does work well in a workstation environment, where temperature is not well controlled and loading is bursty, but will lose some of its advantages in the server environment, at which RHEL is aimed.
(Actually, a thought struck me that the real problem with ntpd may be that the time constant for the phase correction (and poll rate) is tied to that for the frequency correction.)
_______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
