[ntp:questions] Odd (mis)behavior when reference clock fails
kostecke at ntp.org
Tue Sep 23 16:07:44 UTC 2008
On 2008-09-23, Kevin Oberman <oberman at es.net> wrote:
> [---=| Quote block shrinked by t-prot: 40 lines snipped |=---]
>> It would be helpful to know the exact NTP version, and which hardware clock
>> and refclock driver was used.
> It's 4.2.4p4 running on FreeBSD 7.0. The reference clock is a EndRun
> Tech CDMA clock using the TrueTime driver. When the system was running,
> ntpq claimed no successful polls of the reference clock or the PPS. It
> was getting good responses from other systems, but not syncing to
The ntpq peer billboard you posted shows that ntpd _has_ chosen another
system as the sys_peer. See below.
> The offset started small after the clock failed, about .003, and
> steadily grew to over 5 ms. The reference clock always showed a zero
> reachability, delay and offset and .001 jitter.
ntpd has not received any data from the ref-clock. That's one problem.
You may want to check the CDMA clock to make sure that it is actually
The increasing drift is another issue.
> Here is the ntpq -p output after restoring the reference clock to the
> config and letting it run for a few minutes. Drift is already
> # ntpq -p
> remote refid st t when poll reach delay offset jitter
> TRUETIME(1) .CDMA. 0 l - 16 0 0.000 0.000 0.001
> PPS(1) .PPS. 0 l - 16 0 0.000 0.000 0.001
> -time1-owamp.es. .PPS. 1 u 17 64 177 2.058 -10.335 0.038
> *time2-owamp.es. .PPS. 1 u 49 64 177 24.556 -10.408 0.020
> -time3-owamp.es. .PPS. 1 u 63 64 176 55.640 -10.337 0.049
> +time4-owamp.es. .PPS. 1 u 59 64 176 20.770 -10.405 0.058
Is there something about this system which is different from the other
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/
More information about the questions