DragonFly users List (threaded) for 2005-04
Re: NTPD unable to adjust local clock
: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.
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.