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: [EMAIL PROTECTED]
Roedermark, Germany
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
