Unruh wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: > >> Unruh wrote: >>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >>> >>>> Unruh wrote: >>>>> "David J Taylor" <[EMAIL PROTECTED]> writes: >>>>> >>>>>> Hal Murray wrote: >>>>>>>>> Try switching it off, changing the value int he drift file by say >>>>>>>>> 50PPM and >>>>>>>>> then switching it on again, and see how long it takes to recover >>>>>>>>> from that. >>>>>>>> Why would I do that? The drift values rarely change by more than >>>>>>>> five, certainly not by 50. If you are seeing a change of 50, then >>>>>>>> perhaps that it part of your problem? >>>>>>> A big step like that makes it easy to see how the system responds. >>>>>>> At least if it's a linear system. :) >>>>>> Yes, I appreciate that, Hal, but it doesn't emulate the situation here >>>>>> very well, which I understood to be slow convergence after a routine >>>>>> start. It sounds as if the OP may have an incorrect drift file - it's >>>>>> worth checking that it /is/ being updated. >>>>> >>>>> The drift file read 10. The actual drift was 250 (determined after the >>>>> system had settled down). The drift file never changed even after a day of >>>>> running. ntp does not seem to be rewriting the drift file. Now that is a >>>>> problem (although with the apparent Linux bug in the timing routines >>>>> where is >>>>> miscalibrates the clock on bootup, the drift is NOT stable over reboots >>>>> anyway, so the existence of a drift file is irrelevant. ) However, the >>>>> question is >>>>> about the bahaviour of ntp. ntp should NOT be taking 10 hours to get over >>>>> a >>>>> wrong value in the drift file. >>>> That's easy to fix! If the drift file is not correct, remove it before >>>> starting ntpd. >>> Of course. However, I have no idea it is incorrect until after ntp has >>> started up and shown me it was incorrect. >>> >>>> How do you tell if it's incorrect? Since ntpd is supposed to >>>> update/rewrite the drift file every sixty minutes, a drift file more >>>> than sixty minutes old is suspect! >>> I think my problem was that the permissions on /etc/ntp/drift were >>> incorrect ( owned by root rather than by ntp). But that makes no >>> difference to how ntp behaves. ntp should do the "right thing" even if the >>> drift file is wrong. It should take a bit longer, but not 10 hours longer. >>> And with the current apparent bug in Linux wehre the system time is >>> miscalibrated, it would seem that the drift file on Linux is ALWAYS wrong. >>> > >> Do not blame ntpd for the consequences of your errors! If ntpd is >> configured correctly and operated correctly, it behaves quite well. > > ???? I was not blaming ntp for my error. I was blaming ntp for its reaction > to "my error" . And note a bad drift file is now the standard for > Linux. For example between two reboots, my drift rate went from 180PPM to > 250PPM. No drift file would have fixed that. > > NTP handles drift errors badly. But that is not the question I asked. > So far NOONE has answered the > question-- why if my poll internal is 16 sec is the time scale for the > error correction 1 hour? >
How big is the error? Why is your poll interval 16 seconds? (If you are using a refclock, I withdraw the question!) Are you setting the correct time at startup with ntpd -g or ntpdate or sntp? If the drift file is known to be incorrect it's best practice to remove or delete it (depending on which operation your O/S supports) in which case nptd makes no assumptions about the drift and attempts to measure it. A drift file that was last modified more than 60 minutes ago should be assumed to be incorrect. <snip> One very good way to avoid startup problems is leave it running, which I do! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
