[ntp:hackers] Frequency initialization bug
David L. Mills
mills at udel.edu
Sun Mar 6 06:50:44 PST 2005
The bug had nothing to do with the issue of removing or not removing the
frequency file. It had only to do with the kernel frequency
initialization when and only when the "disable kernel" command was
given. If I were to kill you I would need a much more ambitions agenda.
Brian Utterback wrote:
> David L. Mills wrote:
>> Found an evil one which could well explain the occasional frequency
>> torque to +-500 PPM. During initialization the ntpd discipline loop
>> and the kernel loop are initialized from the frequency file. As
>> operation continues, the kernel manages the frequency and ntpd reads
>> whatever the kernel computes, but doesn't do anything with the value
>> other than to calculate the stability for eyeball display and
>> statistics. This all works well.
>> But, if the kernel is explicitly disabled (disable kernel command),
>> the kernel is never called, except at initialization, and that's the
>> rub. Since the configuration file has not been parsed yet, there is
>> no way to know that the kernel frequency should not be initialized as
>> indicated by the disable kernel command. The result is every time
>> ntpd is started the current ntp.drift contents torque the kernel and
>> the daemon then has to compensate for that offset. If the intrinsic
>> hardware error is high, like 300 PPM, the ntpd loop frequency could
>> well hit the stops.
>> I fixed this by moving the loop frequency initialization from
>> ntp_util.c to ntpd.c so it gets called only after configuration is
>> complete. If disable kernel is in the configuration file, the kernel
>> will never be called.
>> hackers mailing list
>> hackers at support.ntp.org
> Dave, you are killing me. I reported this as bug 306 back in August,
> which started much discussion
> through October, and was never resolved because you shot down every
> proposal to change it. You
> said that if the drift file is incorrect, you should just remove it
> before starting ntpd.
> Brian Utterback
> brian.utterback at sun.com
More information about the hackers