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.
The drift-file-accelerated lock-in isn't robust. Current behavior of response isn't very useful for most people experiencing it. Cheers, Magnus _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
