NTPD unable to adjust local clock

[Bill Hacker]

Matthew Dillon wrote:

: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.
Main site at: http://www/ntp.org

A more useful explanation than the 'raw' man pages ('coz these have links)
 can be found at:
http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html

Long list of contributors & who-struck-John on copyright notice page
if it makes sense to confer with anyone:
//www.eecis.udel.edu/~mills/ntp/html/copyright.html

    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.
Some form of periodic comparison is essential, please have a look at:

http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

Figure 2. and the notation w/r results of the all-too-common loss
of connectivity to even a very, very, good clock.
    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.

Once that has been accomplished, some comparative rankings:

=======================================

- Lab-grade cesium-beam, best-case GPS, SONET/SDH Stratum 1:
  ~ 1 second per 100 million years to  ~ 1 second per 10 billion years.
(good enough to confirm the derivation of the Aztec galactic precession 
celestial calendar, but only just.)

- NIST's work in progress on 'chip-scale' atomic clock: ~ 1 second per 
300 years

- NTP typical accuracy, real-world use, not wished-for:  Hard to say.

Short-term - nothing special.  Too many potential glitches.
Long-term - very good.  It is all about the corrections.
    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 at xxxxxxxxxxxxx>
And - for practical reasons to do with file time-stamps, we probably
never want to set a clock in a negative direction - better to exit and
shout for help.
HTH,

Bill