Unruh wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: > >> 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 > > It IS a refclock-- GPS PPS via refclock_shm. > >> are using a refclock, I withdraw the question!) Are you setting the >> correct time at startup with ntpd -g or ntpdate or sntp? > > ntpd -g I am using the shm driver. ntp first uses other servers to set the > time, and then starts the shm pps. The drift is way off, it seems because > of the bug in the linux time driver ( the drift rate changes by 50PPM after > a reboot). > > >> 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. > > I should NOT have to check up on the drift file to see if it is correct. > That is the computer's job. ntp should NOT take 10 hours to correct a wrong > drift file. With a 16 sec poll, ntp should NOT have a 1 hour time constant.
Your opinion! The designers/developers evidently disagree. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
