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? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
