Richard,
You say the initial offset starts out at +90 ms and then "overshoots to
-9 ms". It can't do that; the PLL/FLL impulse response with default poll
interval crosses zero in about 3000 s, then <overshoots> about 6
percent. Even if you set the poll interval to the minimum 16 s, the zero
crossing would be about 750 s with identical overshoot.
What you describe looks like the clock is being set directly, not
disciplined by the PLL/FLL loop, or the adjtime() system call is broken,
as discussed previously. The discipline loop acts as a lowpass filter;
it cannot torque the offset "quickly" as you describe.
I do assume your ntpd code is relatively recent, like in the last year
or two. While some details of the ntpd initial training states have
changed in minor ways, the semi-linear PLL/FLL loop has been unchanged
for some time. The old xntpd code was seriously broken in this area and
displayed ntpq data that could be in serious error.
Dave
Richard B. Gilbert wrote:
David Woolley wrote:
In article <[EMAIL PROTECTED]>,
David L. Mills <[EMAIL PROTECTED]> wrote:
You are victim of faulty engineering intuition. See Chapter 4 in The
Book. See the graphs therein showing the response to initial
Don't have easy access to the book, but looking at the PDF version
of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
discussing here starts in state FSET, gets a type 0 event and
goes to TSET, with no side effects, then gets another type 0 event and
transitions to state SYNC, resetting the stepout timer and starting
to feed the semi-linear part of the control loop. It does this because
the initial error is only 90ms and because there is an ntp.drift
file.
That effectively short circuits the state machine logic after only one
sample, so the start up behaviour is completely dominated by the PLL/FLL.
The person reporting the symptom knows he is using an accurate radio
clock and probably believes that the true phase noise is 100 microseconds
or less, but actually sees the phase take significant time to reach zero
error and then proceed to overshoot to 9ms in the other direction.
I have seen EXACTLY this behavior with ntpd and my Motorola Oncore. Ntpd
started up with a 90 millisecond positive offset, overshot to minus
nine milliseconds. . . . It took about thirty minutes get really
tight synchronization. Solaris 8.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
