[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
>> 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