On 2013-12-07, Magnus Danielson <mag...@rubidium.dyndns.org> wrote: > On 12/07/2013 01:17 AM, unruh wrote: >> On 2013-12-06, Magnus Danielson <mag...@rubidium.dyndns.org> wrote: >>> On 12/06/2013 10:53 AM, Harlan Stenn wrote: >>>> mike cook writes: >>>>>> If you know the drift file is unreliable, you should delete it. ntpd >>>>>> will then perform a frequency calibration before entering the main >>>>>> loop. ... >>>>> This is what has been recommended for ages but it doesn't completely >>>>> fix the issue. It still takes a long time to settle. Here are the >>>>> results of a test I did using the same system and ntp config as in my >>>>> previous reply wit h the unrepresentative drift file data. >>>> An "unrepresentative drift file" is not a "deleted drift file". >>> I filed a bug to address this. If the drift file is obviously nuts, >>> ignore it for speed-up and just work as it was not there, that is, do >>> normal frequency lock-in. >> How does it know that the drift file is obviously nuts? >> >> If it knew that it could fix it. It does not know that. ntpd ONLY knows >> the current offset. Now on bootup if there is not drift file, then it >> tries to remember the past few offsets and use those to estimate a >> drift, but if there is a drift file, it trusts the value in that drift >> file. If you are always going to do a drift estimate for the first few >> polls anyway, why have a drift file at all? > Well, we can discuss which is the best way to detect it, but when you > fail to lock and is forced to re-set the time, then you surely know you > didn't where were you expected to be.
??? There could be all kinds of reasons for that. > > The drift-file-accelerated lock-in isn't robust. Current behavior of > response isn't very useful for most people experiencing it. While I do not particularly want to defend the ntpd philosophy, if you buy that then it does help. Except for those broken Linux kernels which did a really bad job of calibrating their clocks (apparently because that takes time during bootup). Remember that IF you have a good drift file, (ie one that corresponds with the computer drift) then it does speed up convergence. And people keep complaining that ntpd is slow to converge. The boot estimate of drift is a real kludge stuck in there because so many complained that ntpd was so slow to converge. It completely breaks the ntpd philosophy, but only does so on bootup so that is OK:-). As I said, get chrony if you want much faster convergence, if you want better control of the time offset from UTC, and if yourun Linux or BSD. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
