On Fri, Feb 13, 2015 at 05:42:54AM +0000, William Unruh wrote: > On 2015-02-13, Paul <tik-...@bodosom.net> wrote: > > On Thu, Feb 12, 2015 at 7:27 PM, William Unruh <un...@invalid.ca> wrote: > > > >> It was based on measurements I made with ntpd > > > > Are you assuming the numbers I provided are based on theory or were you > > looking over my shoulder when I perturbed system time by two milliseconds > > and watched it converge to O(10) microseconds in ~180 seconds. > > OK, so we seem to have two different sets of experiments with very > different results. Note that I did not erase the drift file, or restart > ntpd after my perturbation.
The difference probably comes from different ntp versions. In some 4.2.7 version the code was reworked to correct the initial offset by adjtime() without touching the PLL. If the drift file contains an accurate value, the PLL should be now able to lock pretty quickly. There is an interesting problem with larger step threshold, however [1]. The code assumes the adjtime() correction can finish in 300 seconds. If the correction is so large that it can't finish before the next clock update, it results in worse behavior than without this feature. On systems that use the standard adjtime() slew rate of 500 ppm the maximum reliable correction is 150 ms, on systems with faster slew it's proprotionally larger. [1] https://bugs.ntp.org/show_bug.cgi?id=2021 -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
