"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. ><snip> >One very good way to avoid startup problems is leave it running, which I do! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
