[ntp:questions] Odd (mis)behavior when reference clock fails

Kevin Oberman oberman at es.net
Tue Sep 23 21:41:34 UTC 2008


> From: Unruh <unruh-spam at physics.ubc.ca>
> Date: Tue, 23 Sep 2008 20:05:48 GMT
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> 
> 
> Steve Kostecke <kostecke at ntp.org> writes:
> 
> >On 2008-09-23, Kevin Oberman <oberman at es.net> wrote:
> 
> >>"Steve Kostecke" <kostecke at ntp.org> wrote:
> >>
> >>> 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 them.
> >>>
> >>> The ntpq peer billboard you posted shows that ntpd _has_ chosen
> >>> another system as the sys_peer. See below.
> >>
> >> Yes, that is quite clear.
> 
> >The sys_peer is the time source that this ntpd is "synced" to.
> 
> >>> >    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
> >>> time servers?
> >>
> >> As stated, all of the servers are identical in terms of hardware and
> >> software and configuration. The only differences in the ntp.conf is that
> >> each system is missing the entry for itself.
> 
> >It is possible that there may a problem with this hardware. Does the
> >clock always drift in the same direction? Do you see periodic clock
> >steps? You may need to adjust the kernel's tick.
> 
> That is precisely what ntp is supposed to do for you. 
> Unless you are suggesting that the clock drift is greater than 500PPM. He
> could look at the drift rate (adjtimex -p  and look at the frequency. 
> The quoted one is in weird units. 
> It looks line frequency/14555 is PPM
> If this is near 500 then you are introuble and have very bad hardware.

I still suspect that you are missing some things I mentioned about the
problem. First, the system syncs to ntp just fine as long as I comment
the reference clocks (truetime and PPS) out. If I simply list all of the
remote ntp servers, it works fine. When the CDMA clock was receiving
time, all was well, too.

Time is very stable and I see the drift at 93.576 ppm. It's a FreeBSD
system, so no adjtimex command. I used ntptime to get the frequency
information. 

Here is a simple table of operation:
Refclock  refclock     refclock not
working   in ntp.conf  in ntp.conf
YES        syncs         syncs
NO         drifts        syncs

The only case of failure is when the reference clock is in the ntp.conf
file and the reference clock is not providing good time. When I say "not
providing time, it is providing time that is pretty close, but it is
marked "No Satellite Lock". It maybe that it is, somehow, still syncing
to the time from that clock, but it is claiming not to have read the
clock at all.

I am very suspicious as the offset I was seeing was only about 5 ms last
week and is 10 ms today. (I have been running with the reference clock
commented out of ntp.conf for that time.)

Another thought...could it be PPS that is causing it? After all, the pin
on the bulkhead connector is still getting the PPS signal. I am using the
kernel PPS implementation, so could that be training the kernel even
though ntp is not using it? 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



More information about the questions mailing list