[ntp:questions] ntpd, boot time, and hot plugging

David L. Mills mills at udel.edu
Thu Feb 10 00:42:04 UTC 2005


The wording is unfortunate. The only thing the -x option does is set the 
step threshold from the default 128 ms to 600 s. The only thing the -g 
option does is allow one and only one panic correction. Tinkering the 
panic threshold to zero completely disables the panic function, as 
panics will never occur and the -g option has no effect.

In general, the 34-year limit is due to integer overflow of the 
first-order differences of 64-bit timestamps. This is documented in a 
white paper on the NTP project page. However, a change made early last 
year extened that limit to 68 years. This was done by converting the 
first-order differences to floating double before the second-order 
differences are computed. You can resume breathing now.


Brad Knowles wrote:
> At 2:05 PM -0200 2005-02-09, Alain wrote:
>>  Putting it in another way: If I configure a workstation with
>>  - ntpd -g
>>  - delete dift file only it it is +-500
>>  - no ntpdate
>>  then the clock will be right even if the clock battery is flat and then
>>  ntpd will go on keeping the clock in synch?
>     Note that the clock does have to be set within 34 years of the real 
> value on bootup.  Otherwise, when ntpd sets the clock, there will be an 
> overflow condition and ntpd won't be able to detect that it has set the 
> clock to a wildly incorrect value.  Many Unix systems today, if they are 
> booted after a BIOS battery failure, will come up with a system clock 
> that has been reset to some time in 1968, 1969, or 1970.  This is now 
> more than 34 years ago, so you will need to make sure that you take 
> appropriate measures under these circumstances.
>     Also note that if your system clock goes whacko after the initial 
> startup, ntpd may choose to commit suicide and exit, and there's nothing 
> you can do to stop that.  Exiting when faced with totally outrageous 
> conditions is a perfectly normal state of affairs with Unix-type 
> daemons, and you need to be prepared to monitor the existence of any 
> critical programs on the system to make sure that they're running 
> correctly.  This is true for ntpd, any other critical program running on 
> the system.
>     Depending on how you have constructed your /etc/ntp.conf file, it 
> may take a little while longer to complete the initialization process.  
> However, those two caveats aside, what you have said is correct.
>>  Even if some messages with the wrong time manage to get to the log 
>> before
>>  the clock is corrected, this can be acceptable for a workstation. I will
>>  just have to figure out how to issue a warning message.
>     That's a normal state of affairs.
>>  What happen if I set the sanity limit to 0?
>     That's what "-g" does.  But it does this only once, on startup. 
> After that, you're on your own.

More information about the questions mailing list