"Rob" <[email protected]> wrote in message news:[email protected]... > Richard B. Gilbert <[email protected]> wrote: >>> * On a system not locking stopping ntp and restarting having set the >>> drift >>> file to -28, results in the drift going back to -400 over a couple of >>> hours - so not some odd start-up state that confuses the control loop. >> >> This suggests that your local clock is defective! Most properly >> working >> hardware will generate an absolute value that is less than 100 and many >> will have an absolute value less than 50. > > I don't think so. This often happens with ntpd, also on systems with > a well working clock. There is some sort of problem with ntpd startup > as Unruh also explained. I have seen it many times. > > It is worse when you start to twiddle the config and shutdown/restart > ntpd often. Then it can take a very long time before it becomes stable > again. > > It seems that the official standpoint is to ignore or deny these > problems, > but that doesn't mean they cease to exist.
I have also seen similar problems where NTP will "go wild", with the computed frequency error becoming further and further from the expected value. Stopping and restarting NTP will sometimes fix these problems, at other times it may be necessary to delete the drift file and let NTP establish a new value from scratch. Cheers, David _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
