[ntp:hackers] Frequency initialization bug
Brian.Utterback at Sun.COM
Sun Mar 6 09:22:58 PST 2005
Nevertheless, it is the same bug. Removing the file was your workaround.
No file, no initialization.
Well, Dave, I am over my shortlived desire for self-destruction and will
try to refrain from providing
you with that agenda.Besides, I will be too busy hiding under my bed
this week, since Friday the
13th falls on a Sunday this month. Specifically, next Sunday. Horrors!
Harlan, I believe that this should address bug 306 and it can be closed.
David L. Mills wrote:
> 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
> hackers mailing list
> hackers at support.ntp.org
More information about the hackers