Re: NTPD unable to adjust local clock

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Wed, Apr 06, 2005 at 10:36:23AM -0700, Matthew Dillon wrote:
>     It's a little more complicated then that, but it's doable.  Actually
>     it's a lot more complicated then that.

No risk, no fun :)

>     First, we have to do away with ntpd's code that tries to take the
>     average from multiple time sources.  What a disaster that is!  At
>     the very *best* we can have a heuristic based on the offsets from
>     each source to try to correct the offsets, but otherwise we have to
>     choose the best time source (lowest standard deviation at the lowest
>     stratum) and stick with it.  None of this averaging between sources
>     business.  Each time source has to be independantly tracked and we
>     pick the best one, period.

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.

>     Second, it takes at least 8 samples from any given source over several
>     minutes (the longer the interval the more accurate the calculation)
>     before we can even come close to having an accurate enough 'rough'
>     frequency error estimation.  It takes at least several minutes worth
>     of samples.  Frequency errors often operate on a parts-per-million 
>     scale or a parts-per-billion basis.

Yes, I'm very well aware of it. I'm reading the original NTP papers and
will do some matth myself. Once we have done that, I'd like to add the
ability to record the frequency in a file, similiar to what DJB's program
[what ever it was named] does. That would allow e.g. notebooks without
permanent connection to still somewhat correct the local time.

I'm also aware that I have to keep track of the corrections already done,
but it still is very isolated code, just that it ends up cleaning other
code as well.

Joerg
>     The standard
>     system adjtime() call should only be used in an emergency, such as if
>     the time is say greater then 10 minutes off, or not used at all.

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