Richard,
The overshoot is the result of a misdirected Solaris/Linux design of the
adjtime() system call. The design added a poll to the transfer function
in order to speed the response to a programmed offset. The result
completely torpedoes the PLL transient response and there is nothing
that can be done to correct it in ntpd itself. What you see is what you
get. The problem is most apparent with large initial frequency offsets,
which are guaranteed to result in pinball behavior. Note the overshoots
do not occur in FreeBSD or Tru64, which have a reasonable design.
Dave
Richard B. Gilbert wrote:
Bart Van Assche wrote:
As known the PLL implemented in ntpd/ntp_loopfilter.c can overshoot.
In the source code of ntpd 4.1.2 it is documented that this overshoot
is less than 5 percent. Measurements I performed confirm this.
The PLL algorithms in ntpd 4.1.x and are 4.2.x different. The source
code of ntpd 4.2.0 specifies that document UDel TR 97-4-3 documents
the ntpd 4.2 PLL algorithm. Anyone any idea where I can find that
document ? I could not find it via Google, and it's not in David Mills
list of papers (http://www.cis.udel.edu/~mills/papers.html). I'm
asking this because for ntpd 4.2.0 I measured an overshoot of about
100 percent. Can anyone confirm this ?
I can't confirm the 100 percent but the current version doesn't work too
well with my GPS reference clock at startup! I had something like a 90
millisecond offset when I started ntpd. Over the next few minutes it
corrected that offset but didn't stop, or even slow down, when it hit
the zero line. It kept right on going until it had a -9 millisecond
offset. It took about thirty minutes lock in tightly! I could have
figured it out with pencil and paper in less time than that and, as a
mathematician, I can't count to twenty with my shoes on!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
