[ntp:questions] Stabilizing the drift file?

mills at udel.edu mills at udel.edu
Mon Nov 27 17:00:59 UTC 2006


Juergen,

You are badly misguided. While the resolution of your Linux (and many 
other systems) system clock might be better than a microsecond, the 
precision of reading it can be much worse, Moreover, you haven't 
calibrated for the maximum intrinsic error in reading the system clock 
upon reboot, which can be in the many milliseconds, much more if the TOY 
clock chip cannot be read to that precision. Suggesting that you can 
with confidence estimate the intrinsic clock frequency within a PPM 
after two seconds of observation is statistical irresponsibility. I said 
what I said; now we should get on to other business.

Dave

Juergen.Salm at siemens.com wrote:

> mills at udel.edu wrote :
> 
> 
>>When first starting ntpd without the drift file, by default the state
>>machine takes fifteen minutes to directly compute the initial frequency
>>estimate within about 1 PPM, then enables the native clock discipline
>>algorithm.
> 
> 
> Hi Dave.
> 
> You statement is correct for the complete variety of platforms ntp
> supports.
> However, on a Linux system (with at least 1us time resolution) you can
> get reasonable estimates for the drift much faster.
> Have a look at my script in
> https://ntp.isc.org/bugs/show_bug.cgi?id=742
> Changing the stepout as you proposed should give the same results (on
> Linux).
> Unfortunately, I didn't understand the meaning of 'stepout' from the
> documentation. ;-(
> 
> Bye
>  Juergen
> 




More information about the questions mailing list