[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    [ntp:bugs] [Bug 740] New: The frequency in the kernel time
From:       bugzilla () ntp ! isc ! org
Date:       2006-11-20 14:34:35
Message-ID: 20061120143435.68C62398A3 () ntp2 ! ntp ! isc ! org
[Download RAW message or body]

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

           Summary: The frequency in the kernel time discipline is
                    initialized from the drift file, even when the kernel
                    time discipline itself is not used
           Product: ntp
           Version: 4.2.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: ntpd
        AssignedTo: stenn@ntp.org
        ReportedBy: Juergen.Salm@siemens.com
                CC: bugs@ntp.isc.org


When using the '-x' command line option or setting the step threshold to 0 or 
larger than 128ms, the documentation says.

Note: The kernel time discipline is disabled with this option.
Note: The kernel time discipline is disabled if the step threshold is set to 
zero or greater than the default.

However, even under these conditions, the frequency is initialized from the 
drift file.

This leads to the following strange effect.

Let's say we have a real drift of 70ppm, while the drift file says 50.000.

When ntpd is started, the frequency in the kernel time discipline will be 
initialized to 50ppm Afterwards, ntpd will measure 20ppm (the different that is 
not already compensated by the kernel) and write this value to the drift file.
Next time when ntpd is started, the kernel time discipline will be initialized 
with 20pp and ntpd will measure 50ppm and write is to the drift file.

So every time ntpd is started, the drift will alternate between 20ppm and 50ppm.

Or more general, between x-a and x-b, with x as the real drift and b = x-a.

Well, this is funny to watch but is brings an unnecessary long transition 
period at every ntpd restart, before thing get stable.

I've corrected the behavior with the following modification.

diff -r ntp-dev-4.2.3p64-RC/ntpd/ntp_loopfilter.c ntp-dev-4.2.3p64-RC-
modified_Salm/ntpd/ntp_loopfilter.c
988c988
<               if (pll_control && kern_enable) {
---
>               if (pll_control && kern_enable && clock_max <= CLOCK_MAX 
> ) {

I don't know whether this is the right place and the right way to fix the 
problem. (I even don't know if you see this as a problem.) But it works fine 
for me. ;-)

Bye
	Juergen Salm

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



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bugs mailing list
bugs@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/bugs
[prev in list] [next in list] [prev in thread] [next in thread]