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 [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] 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 > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
