Re: NTPD unable to adjust local clock

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Tue, Apr 05, 2005 at 06:44:33PM -0700, Matthew Dillon wrote:
:>     After the release we are either going to have to go back to the ntpd 
:>     we had before, or we are going to have to make some major changes to
:>     OpenBSD's code.  The code looks clean enough that we can probably make
:>     the required changes, but the work is going to be a bit too involved to
:>     maintain it as a contrib and a patch set... we'd have to import the
:>     code for real and maintain it in our tree.
:
:No xntpd please. I'm much more willing to write the actual slew algorithm
:for OpenNTPD, which already has all the network code, only the actual adjust
:has to be improved. I'm also quite sure that Henning would include it in
:OpenNTPD.
:
:Joerg

    It's a little more complicated then that, but it's doable.  Actually
    it's a lot more complicated then that.

    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.

    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.

    Third, when we actually set the PLL via the timex.offset and timex.freq
    arguments, we have to then keep track of what we have done so we can
    'undo' it in our raw calculations against the time sources (e.g. so if
    we calculating a 23ppm frequency error and correct for it via timex,
    that we then compensate for the fact that we corrected it in further
    calculations so we aren't suddenly calculating a 0ppm frequency error
    due to the prior correction).

    It all comes down to calculating timex.offset and timex.freq.  These
    can be treated almost independantly.  The offset corrects offset errors
    (an offset error does not necessarily imply a frequency error), while
    the freq is a permanent frequency error correction.  It takes a LONG time
    to home in on the frequency correction.  Offset corrections are applied
    slowly.  Frequency corrections are immediate.  I think there's a way
    to query the system how much offset has yet to be applied but I forget
    how.  This is all done with the ntp_adjtime() call.   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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>