On 2013-04-28, Harlan Stenn <st...@ntp.org> wrote: > unruh writes: > >> I advise to subtract 20 from the drift file to give an estimate of how >> fast ntpd recovers from a wrong drift, not that that is the perferred >> way of operating. Note that Linux for a while would vary in the rate >> from bootup to bootup by up to 50PPM, and ntpd-- operating as >> designed-- would have to try to recover from that. Ie, a wrong drift >> value is NOT a complely out of this world situation. Similarly, a >> machine drifting out by 100ms is also not out of the oridinary for a >> lengthy shutdown (esp since the rtc is uncorrected.) If it is out by >> more, then the stepping of ntpd will come into play. > > For years I've wanted the drift file to include the frequency/tick > values in-use when the drift file was written. Doing this would allow > ntpd to know if the tick value or frequency that it reads from the drift > file matches the current operating values or not, and take appropriate > steps.
I am not sure, but I thought that in the case of the Linux inability to consistantly calibrate the system clock, the frequency and tick values were always 0. It was the calibration behind the scenes which set what 0 meant that was at fault. Obviouly if the user changes those values (to bring the drift closer to zero for example so ntpd is not working so hard trying to compensate for a "way off" calibration) then ntpd should know about it. > > H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
