[ntp:questions] iburst

David L. Mills mills at udel.edu
Mon Nov 27 21:39:59 UTC 2006


The units recorded in the frequency file are in precise 
parts-per-million (PPM) maintained to a precision of parts-per-billion 
(PPB). Properly calibrated, it makes an excellent room thermometer, fire 
alarm and fan tattletale.


David Woolley wrote:
> In article <%crah.14971$Uz.9028 at trnddc05>,
> terrypearl <fastsnip-bcard at yahoo.com> wrote:
>>driftfile: -21.719
>>good? bad ? indifferent ?
> Without knowing the frequency error of the timing crystal in the PC, it's
> impossible to say.
> What was meant by the question was:  does the value in your driftfile 
> accurately reflect the correction needed to maintain the steady state?
> Because you are not keeping the machine up for very long at any one time,
> it is possible that the drift value never properly converges, so the
> value is not particularly accurate.  If you didn't have a drift file at
> all, or if it is unreadable to ntpd, ntpd would have spent about 15
> minutes trying to calculate the frequency error, before setting the
> time.  However, I'm not really sure how you define "achieve synch".
> (Also, as you say you use Linux, Linux shares, with Windows, a tendendency
> to lose clock interrrupts, which can severely disrupt the ability to maintain
> accurate time.)
> Incidentally, although I haven't tried it in anger, I believe that a system
> with a good driftfile value will achieve low offsets faster if it is 
> started with an offset of more than 128ms.  Below that, gentle corrections
> are applied, but, above it, a step correction is applied.
> As to leaving the machine on, that is very good advice for precision time
> synchronisation protocols, like NTP.  We cannot know when people are
> under severe financial constraints if they don't tell us.

More information about the questions mailing list