[ntp:questions] Re: HowTo calibrate system clock frequency using NTP

Terje Mathisen terje.mathisen at hda.hydro.com
Fri Feb 3 11:02:16 UTC 2006


David Woolley wrote:
> In article <bjaab3-qff.ln1 at osl016lin.hda.hydro.com>,
> Terje Mathisen <terje.mathisen at hda.hydro.com> wrote:
> 
>> Afaik ntp.drift normally carries about an hour's worth of history.
> 
> The complete control loop for ntpd has an infinite impulse response,
> so the ntp.drift value has an infinite history.  The period that 
> accounts for most of the contribution to the value depends on an 
> adaptive algorithm that starts by making the response fast and slows
> it down as confidence increases, reducing it again if confidence drops.
> This is related to the poll interval, but not in a simple way.

Right, I should possibly have mentioned how most of the statistical 
measures use exponential averaging, but I was just trying to persuade 
the OP that it was unrealistic to expect better than PPM agreement 
between various methods to determine the "average" drift value.

Mea culpa.

(My MS is in EE, so I'm supposed to know a bit about control theory as 
well. :-)
> 
> Nick McClaren, has, in the past, proposed the use of finite impulse
> response processing, but using a statistical fit, rather than the 
> current, to a first approximation, linear feedback loop.  That's 
> basically having it continually do linear regressions.
> 
> (The big problems seem to be that the response is still too slow when
> initially acquiring lock and the frequency response time is reduced too
> much after a subsequent time step (lost interrupt, server hop, or people
> breaking the clock to test the ability to track the time).)
> 
> Incidentally, I find a simple average is good enough to get 30 second
> a year accuracy in an air conditioned environment, providing you do it
> over about a week.

I first did this around 1985 when I wrote a DOS TSR program (remember 
those?) which took over all timing-related functions in the OS & BIOS. I 
calibrated it with two modem calls to the swedish UTC clock facility, 
with 24 hours between them, then let it free-run for a week.

The resulting offset was 60 ms. :-)

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list