Dave, [EMAIL PROTECTED] 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: http://www.meinberg.de/download/ntp/graphs/ntp-4.2.3p51.pdf 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: http://www.meinberg.de/download/ntp/graphs/ntp-4.0.99.pdf 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 expect. We can take a closer look at the startup of 4.0.99: http://www.meinberg.de/download/ntp/graphs/ntp-4.0.99.startup.pdf 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 correction. 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 -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
