On Mon, Nov 7, 2011 at 21:58, unruh <[email protected]> wrote: > Actually, that is not the way that ntpd works. It has no concept of > "frequency error".
Sure does, the frequency error is the frequency= value reported by ntpq, internally in ntpd stored in drift_comp, and persisted between runs in the driftfile. Perhaps you were thinking of short-term frequency error due to temperature changes? > All it knows is the offset. It then changes the > frequency in order to correct the offset. It does not correct the offset > directly. The offset is corrected directly when it exceeds the step threshold, 128 msec by default. > It never figures out what the frequency error is. Sure it does, when started without a driftfile. > All it does > is "If offset is positive, speed up the clock, if negative slow it down" > ( where I am defining the offset at "'true' time- system clock time"). > (There is lots that goes into ntp's best estimate of the 'true' time, > which is irrelevant to this discussion) Irrelevant if you want to paper over the minimum delay clock filter, which you love to disparage and I view as a key error reduction step. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
