Re: TS-7200: time sync issues

[Ken Hornstein <kenh%cmf.nrl.navy.mil@localhost>]

>: I'm sorry if this wasn't clear ... but the problem seems to be within
>: the settimeofday() (or perhaps clock_settime()) function.  Once ntpd
>: gets "lucky" and gets the clock within 128ms, it's happy.  Right now
>: my TS-7200 box has been up for over a day without any time steps, and
>: ntptime shows a frequency of -51 ppm.
>
>Why must this be the case? ntpd doesn't even use these functions.

Respectfully ... you are wrong (about ntpd not using these functions).

When the time is stepped, ntpd calls step_systime().  step_systime()
calls ntp_set_tod().  ntp_set_tod() calls clock_settime() or settimeofday().
I am of course speaking about the ntpd that ships with NetBSD.

>You'd get the same problem if your frequency was wrong, or if you were
>missing clock interrupts so that time would run slow.

Yeah .... but that still doesn't explain why it syncs up fine once
it gets within the offset threshold for frequency adjustment.

>What happens if you do two ntpdates in a row?

ts7200# ntpdate timeserver
 9 Dec 23:51:48 ntpdate[587]: step time server 192.168.0.1 offset 0.620005 sec
ts7200# !!
ntpdate timeserver
 9 Dec 23:51:54 ntpdate[554]: step time server 192.168.0.1 offset 0.723242 sec
ts7200# !!
ntpdate timeserver
 9 Dec 23:51:55 ntpdate[564]: adjust time server 192.168.0.1 offset 0.332673 sec
ts7200# !!
ntpdate timeserver
 9 Dec 23:51:57 ntpdate[41]: adjust time server 192.168.0.1 offset 0.326644 sec

>Also, you are reading the logs wrong.  ntpd does a poll every 1024
>seconds.

I didn't get into my setup at all .... but in this particular
configuration my TS-7200 is a broadcast ntp client, and that broadcast
happens ... every 64 seconds?  Something like that.  I don't think
that is an issue, as other systems using the same broadcast server
don't have any problems.

Simon Burge <simonb%netbsd.org@localhost>
>I'd guess some catastrophic arithmetic error in the time counter code
>(see other examples of wrong mask earlier in this thread) or clock
>interrupts being blocked for too long.
>
>With ntpd disabled, what does something like:
>[...]

Yeah, that shows a relatively small amount of drift, nothing like above:

 9 Dec 23:58:16 ntpdate[494]: adjust time server 192.168.0.1 offset 0.301362 sec
 9 Dec 23:58:17 ntpdate[756]: adjust time server 192.168.0.1 offset 0.301358 sec
 9 Dec 23:58:19 ntpdate[780]: adjust time server 192.168.0.1 offset 0.301344 sec
 9 Dec 23:58:20 ntpdate[762]: adjust time server 192.168.0.1 offset 0.301336 sec

Really, you can easily force the problem no matter what the offset is
by doing "ntpdate -b".  E.g.:

client# ntpdate -q timeserver
10 Dec 00:06:06 ntpdate[920]: adjust time server 192.168.0.1 offset -0.039474 
sec
ntpdate -q timeserver
server 192.168.0.1, stratum 3, offset -0.033536, delay 0.02690
10 Dec 00:06:37 ntpdate[911]: adjust time server 192.168.0.1 offset -0.033536 
sec
client# !!
ntpdate -q timeserver
server 192.168.0.1, stratum 3, offset -0.033144, delay 0.02689
10 Dec 00:06:39 ntpdate[884]: adjust time server 192.168.0.1 offset -0.033144 se
client# ntpdate -b timeserver
10 Dec 00:07:06 ntpdate[907]: step time server 192.168.0.1 offset -0.028554 sec
client# ntpdate -q timeserver
server 192.168.0.1, stratum 3, offset 0.786812, delay 0.02689
10 Dec 00:07:13 ntpdate[361]: step time server 192.168.0.1 offset 0.786812 sec

I'm not trying to be an obstinate bastard, honest.  I really do
appreciate the help.  I just can't convince myself that this is a
frequency problem.  My best guesses are that clock interrupts are
blocked for too long when setting the TOD clock, or there is some
strange arithmatic error when the time is set.

The reason I don't think it's a frequency problem is that I _did_
have a frequency problem back on my Net4501.  That turned out to
be a particular issue with the ElanSC having a slightly different
clock than the standard PC one.  In that case ntpd would never sync
up and just continually stepped all the time.  Like I said, once
the TS-7200 gets the clock within 128ms, ntpd switches to only doing
frequency adjustments and then there are no further time steps.

--Ken