[ntp:bugs] [Bug 778] ntpd fails to lock with drift=+500 when started with drift=-500

[Stephen Casner via the NTP Bugzilla]

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



----------------------------------------------------------------------------
Additional Comments From casner at packetdesign.com (Stephen Casner)
Submitted on 2007-02-13 03:43

(In reply to comment #6)
> If you have tinkered the -x above the default step interval, the NTP 
> kernel aupport is completely disabled and will not be used for anything. 

I have supplied -x and -g as command line arguments, but none of the parameters
have been tinkered otherwise.

> In principle, the daemon works just fine in this case, but there is an 
> unforgiving downside. If the resulting computed frequency correction is 
> greater than 500 PPM, neither ntpd nor the standard Unix kernel 
> adjtime() system call can can handle that.

Does that mean if it calculates a correction greater than 500 PPM it gives up
and never recovers?  What I observed was that when started with drift=-500 the
drift value started heading toward zero but then shot right past and went to
+500 over the course of 12 hours.  It did not recover in 63 hours of operation.

> If you are going to test, make sure you zero the kernel frequency first, 
> as it will remember the last valid frequency offset before it was 
> disabled, which is not what you want.

Do you mean the /etc/ntp/drift value?  Or an internal variable?  If the latter,
since I'm starting with -x I would assume the kernel is not invoked at all.

I acknowledge that the daemon should not be started with a drift file of -500 or
+500.  I can add some code the delete the file when it is in either of those
states.  I presume that I should not always delete the drift file before
starting the daemon, though; otherwise there would be no point in writing it.

My purpose in filing this bug was to find out whether 4.2.4 still remains
vulnerable to getting stuck and heading off into the giggleweeds, as in bug 628.
 We have seen situations where restarting the 4.2.0 daemon with a valid drift
value causes it to go haywire.  I'll include some more information in some
attachments.

> If you really want to completely gut the kernel, compile without
> the KERNEL_PLL define.

As I said in Comment #4, I would really rather use the kernel PLL, but I need
some way to protect against the time being stepped backwards.

-- 
Stephen Casner <casner at packetdesign.com>



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