Re: NTPD unable to adjust local clock

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.

    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.

    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.

: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

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>