DragonFly users List (threaded) for 2005-04
Re: NTPD unable to adjust local clock
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
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:
Long list of contributors & who-struck-John on copyright notice page
if it makes sense to confer with anyone:
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:
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
- 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.
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.