NTPD unable to adjust local clock

[Joerg Sonnenberger]

On Wed, Apr 06, 2005 at 11:10:11AM -0700, Matthew Dillon wrote:
> :It's not that simple. You have to ensure that even a low-stratum source
> :(perhaps with the exception of stratum 0 aka local time source) isn't
> :horrible wrong to prevent an upstream time server from changing your
> :local time, just because it is the lowest source reachable. That's asking
> :for a DOS exploit.
> 
>     Mmm... averaging time sources is not going to make the problem work
>     out any better.  All averaging time sources does is add confusion.
>     Believe me, you do NOT want to average time sources.  You can put in
>     sanity checks, but don't average time sources.

I agree. Let me do the math :)

>     In anycase, I'll be happy to test whatever you come up with.  We need
>     to get this done in the next few months, though, we can't let it hang
>     for another year.

Sure.

> :Once we use ntp_adjtime [or a similiar syscall, I have to check first],
> :there isn't any reason to use adjtime anymore. To handle large offsets,
> :you still pretty much need settimeofday.
> :
> :Joerg
> 
>     Correct, but beware improperly calling settimeofday() simply due to
>     a clock's frequency error being large.  e.g. after doing an initial
>     settimeofday() a 5 minute sampling delay could cause the error to exceed
>     whatever threshold had been set and ntpd would wind up just doing steps
>     and *never* being able to fix the frequency.  Or something of that
>     nature.  At the same time, you can't correct a frequency error, even 
>     a horrendously bad one, with just a few samples.. it still takes a
>     a good 8 samples and a standard-deviation calculation to know that
>     you've got a real, correctable frequency drift.

Under normal operation, a large drift (> 180 seconds) should never appear.
At boot time, it's something different, we can somewhat safely call
settimeofday there, even when we have very few samples. That's what
ntpd already does by default.

Joerg