[ntp:questions] iburst
David L. Mills
mills at udel.edu
Mon Nov 27 21:39:59 UTC 2006
David,
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.
Dave
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