[ntp:questions] Re: ntpd PLL and clock overshoot

Martin Burnicki martin.burnicki at meinberg.de
Wed Oct 18 10:34:29 UTC 2006


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.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list