[ntp:questions] Re: ntpd PLL and clock overshoot
user at domain.invalid
user at domain.invalid
Wed Oct 18 15:49:15 UTC 2006
I don't know wehat to tell you. I have about two dozen machines nearby
that do not behave as you report. First, be sure to understand the phase
(offset) response is strictly proportional to the poll interval. At the
default poll interval of 64 s, the offset crosses zero in about 3000 s.
However, if there is significant frequency error, that can take much
longer (hours to a day) to converge. Meanwhile, the poll interval might
have ramped up due the intended design, so the convergence can be much
longer. That is the intended design; once the initial phase/frequency
transient has subsided, the time offsets in a configuration like yours
are normally less than 100 microseconds. See rackety.udel.edu and/or
pogo.udel.edu with ntpq for nominal behavior.
Martin Burnicki wrote:
> user at domain.invalid wrote:
>>I beg to seriously differ. To the extent the z transform of the impulse
>>response preserves the poles and zeros of the poplynomial
>>representation, the digital NTP loop behaves as an analog loop, at least
>>in the linear regime of operation.
>>The initial frequency estimate measures only the frequency offset; the
>>phase offset is left to fend for itsel, which could indeed result in an
>>initial offset exceeding the "overshoot" target. The purpose of the
>>state machine in the first place is to allow large initial poll
>>intervals, as with telephone modem services.
> It's been a long time since I've learned the basics of control, and I'm not
> as familiar with the maths as you are. However, I've heard many people
> saying that the current implementation of the control loop is very slow,
> whereas it has converged faster in earlier implementations of ntpd.
> I've run some simple tests on Windows 2000 machine which has a single
> upstram NTP server configured. The upstream server is a GPS based stratum-1
> machine under Linux on the local LAN, and the time differences on the
> client have been computed between the local system time and a GPS PCI card
> plugged into the client.
> Please note the initial offset of a few milliseconds which is intentional in
> order to see how the filters converge. This is the result of a recent
> ntp-dev version ntp-4.2.3p51:
> You see it takes about 100000 seconds (more than a day!) to get from about
> 15 milliseconds down to about 2 milliseconds offset.
> As a comparison I've done the same once more with a pretty old version of
> ntpd, ntp-4.0.99:
> The older implementation of ntpd is compensating the initial offset in about
> 20000 seconds, more than 5 hours, which is still more than one would
> We can take a closer look at the startup of 4.0.99:
> During the first 200 seconds we see the initial step of the system time, and
> the drift of the system time while the tick adjustment value is at its
> default value.
> Then ntpd starts to correct the initial offset properly in less than 300
> seconds. This looks like it was going to converge properly. However,
> unfortunately at a 10 ms offset the filter algorithm seems to switch and
> the following correction is still very poor compared to the initial
> I think even though a very slow correction could be useful for some systems
> with polling rates of 36 hours and more, most installed instances of ntpd
> could provide much better performance with a faster control loop.
> And, this does not seem to be a Windows problem since we also have observed
> this slow convergence under different operating systems.
More information about the questions