[ntp:bugs] [Bug 740] The frequency in the kernel time discipline is initialized from the drift file, even when the kernel time discipline itself is not used

[Juergen Salm via the NTP Bugzilla]

http://bugs.ntp.isc.org/740


Juergen.Salm at siemens.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |READY


----------------------------------------------------------------------------
Additional Comments From Juergen.Salm at siemens.com (Juergen Salm)
Submitted on 2007-04-16 16:58

Hi Harlan.

I've tested it with 4.2.4p0 and the problem still exists in this version.

I try to explain what happens with the wording introduced above.

When starting up, ntpd initialized the kernel freq AND the daemon frequency
with the value from the drift file. Unfortunately, in "-x" mode, the actual
frequency is the sum of kernel frequency and daemon frequency. Therefore, ntpd
will "correct" the daemon frequency from the initial value to the residual
error that is not compensated by the kernel freq during the first few hours
of operation (which leads to unnecessary large time offsets) and it writes
this value to the drift file.

In consequence, the long term values of the kernel freq and the daemon freq
toggle each time ntpd is restarted. ;-(

BTW: I fully understand why Dave wants to initialize the kernel freq with the
value from the drift file even in "-x" mode.

Version dev-4.2.5p20 seems to be much smarter. While the kernel freq is still
initialized from the drift file, the deamon seems to be aware of the fact that
is only measures the remainig offset. The values from the log file and the
loopstats look good and so the value written to the drift file is also fine.

-> The problem seems to be fixed in dev-4.2.50p20. I'll set the status to 
RESOLVED.

Bye
 Juergen


-- 
Juergen Salm <Juergen.Salm at siemens.com>



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.