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

[David L. Mills]

Brad,

Geeze, I took hits on the web documentation to clarify the meaning and 
reworded it. I forgot all about the program comments. Wow; can't get 
away with everything. I checked all three thresholds; if tinkered to 
zero, the threshold is completely ignored.

The 34->68-year fix went in soon after 1 January 2004 for the obvious 
reason.

Drink deep, water brother.

Dave

brad at shub-internet.org wrote:
> "David L. Mills" <mills at udel.edu> wrote:
> 
> 
>>                                              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.
> 
> 
> I was looking at ntpd/ntp_loopfilter.c, and got confused by this comment,
> starting at line 234:
> 
>         /*
>          * If the clock is way off, panic is declared. The clock_panic
>          * defaults to 1000 s; if set to zero, the panic will never
>          * occur. The allow_panic defaults to FALSE, so the first panic
>          * will exit. It can be set TRUE by a command line option, in
>          * which case the clock will be set anyway and time marches on.
>          * But, allow_panic will be set FALSE when the update is less
>          * than the step threshold; so, subsequent panics will exit.
>          */
> 
> I never claimed to grok what the code itself was actually doing, but my
> reading of that comment does not correspond with the explanation you just
> gave.  Can you clarifiy?
> 
> 
>>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.
> 
> 
> When was this done?  Just a few days ago, I had the system come up with a
> bogus BIOS clock date set to 1 Jan 1970, and after sync'ing to upstream
> time servers, ntpd reset my clock to something in 1934.  I'd like to know
> when this change went in, so that I would have some idea of what might have
> happened on my system if it was not the fault of ntpd having an overflow
> problem.
>