[ntp:questions] Re: Solairs 8 xntpd client oscillates

[Joachim Schrod]

Brian Utterback wrote:
> 
> I don't know what your problem is, but I have a couple of observations.
> 
> First, it seems pretty odd that the second reset in the log is for
> exactly the same offset and seems to have the same timestamp as the
> first reset.

Sorry, this was a copy&paste error. I copied first the lines until the first 
synchronization, and then made an error when I copied the next lines.
Here is a copy&paste in one batch:

  8 May 15:10:58 xntpd[1167]: time reset (step) 1.517708 s
  8 May 15:10:58 xntpd[1167]: synchronisation lost
  8 May 15:10:58 xntpd[1167]: system event 'event_clock_reset' (0x05) status 
'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xc0f4)
  8 May 15:10:58 xntpd[1167]: system event 'event_sync_chg' (0x03) status 
'sync_alarm, sync_unspec, 15 events, event_clock_reset' (0xc0f5)
  8 May 15:10:58 xntpd[1167]: system event 'event_peer/strat_chg' (0x04) status 
'sync_alarm, sync_unspec, 15 events, event_sync_chg' (0xc0f3)
  8 May 15:12:01 xntpd[1167]: peer LOCAL(0) event 'event_reach' (0x84) status 
'unreach, conf, 4 events, event_reach' (0x8044)
  8 May 15:12:02 xntpd[1167]: peer 192.168.129.1 event 'event_reach' (0x84) 
status 'reach, conf, 4 events, event_reach' (0x9044)
  8 May 15:16:17 xntpd[1167]: synchronized to LOCAL(0), stratum=10
  8 May 15:16:17 xntpd[1167]: system event 'event_sync_chg' (0x03) status 
'leap_none, sync_local_proto, 15 events, event_peer/strat_chg' (0x5f4)
  8 May 15:16:17 xntpd[1167]: system event 'event_peer/strat_chg' (0x04) status 
'leap_none, sync_local_proto, 15 events, event_sync_chg' (0x5f3)
  8 May 15:16:18 xntpd[1167]: synchronized to 192.168.129.1, stratum=2
  8 May 15:32:19 xntpd[1167]: time reset (step) 1.517174 s
  8 May 15:32:19 xntpd[1167]: synchronisation lost
  8 May 15:32:19 xntpd[1167]: system event 'event_clock_reset' (0x05) status 
'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xc0f4)

As you see, that "time reset" phenomenon happens all the time again. Typically, 
between

> Further, offsets shown in readvar output show severe drift, but this
> could be due to NTP's attempt to correct the clock. Since this
> output is sorted, I can't really tell if the clock is diverging
> or converging.

It's diverging all the time. Then, after some time, comes the "time reset" and 
the "synchronisation lost" messages, then the peer command does not show any 
synchronizations any more. For example:

      remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
  LOCAL(0)        LOCAL(0)        10 l   63   64    3     0.00    0.000 7885.01
  lion.npc.de     ptbtime2.ptb.de  2 u   62   64    3     0.44  150.355 7913.01


> One possibility is that you are a victim of a misbehaving hardware
> TOD clock. Another is that you have a process that is syncing the
> clock periodically to a different server.

I have checked all running processes and all cron jobs and am sure that this is 
not the case.

> Another is that your system clock drifts radically.

If that's the case, would xntpd not work for my system? Can this be influenced 
on Sun workstations?

> Here is what I suggest. First lose the LOCAL refclock. It does nothing
> for you. Second, unless you are using the slewalways option, lose the
> "disable pll". Since you don't show either in your config file, I can't
> tell which you need.
> 
> Third, configure the stats file. That is the only way you are going to
> get enough data to be able to even guess.
> 
> Fourth, stop xntpd, delete the drift file and reboot. Do not just
> restart xntpd. You may have a bogus drift value in the kernel and
> in the drift file.

OK, done all that. (I didn't use the "disable pll" currently anyhow; this was 
just an intermediate test triggered by a recommendation for Solaris 8 that I 
found on the Net.) If the clock doesn't stabilize, I'll come back and make the 
statistics files accessible.

Thanks,

	Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: jschrod at acm.org
Roedermark, Germany