[ntp:questions] NTP offset doesn't change.

Miroslav Lichvar mlichvar at redhat.com
Fri Feb 13 09:27:21 UTC 2015


On Fri, Feb 13, 2015 at 05:42:54AM +0000, William Unruh wrote:
> On 2015-02-13, Paul <tik-tok at bodosom.net> wrote:
> > On Thu, Feb 12, 2015 at 7:27 PM, William Unruh <unruh at 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


More information about the questions mailing list