Re: NTPD unable to adjust local clock

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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@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