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