[EMAIL PROTECTED] wrote: > Is something else other than NTP hitting the system clock? > > Paul >
Until we see the requested data, we won't know for sure, but this sequence is a little confusing: 27 Jun 06:57:05 xntpd[10412]: adj_systime(0.000007164 sec): offset = -0.000108698 sec 27 Jun 06:57:05 xntpd[10412]: time reset (step) 0.499364 s 27 Jun 06:57:05 xntpd[10412]: synchronisation lost 27 Jun 06:57:05 xntpd[10412]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 6 events, event_peer/strat_chg' (0xc064) 27 Jun 06:57:05 xntpd[10412]: system event 'event_sync_chg' (0x03) status 'sync_alarm, sync_unspec, 7 events, event_clock_reset' (0xc075) 27 Jun 06:57:05 xntpd[10412]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_unspec, 8 events, event_sync_chg' (0xc083) 27 Jun 06:57:06 xntpd[10412]: adj_systime(0.000007164 sec): offset = 0.499262365 sec 27 Jun 06:57:07 xntpd[10412]: adj_systime(0.000007164 sec): offset = 0.400269532 sec The offset is near 0, then xntpd does a 0.499 sec step forward and the offset afterward is still another(?) 0.499 sec. It might suggest that the server did a 1 second step forward or that the client did a 1 second step backward and that xntpd is responding to that with a combination step and slew. However, it could also be, as I mentioned previously, that there is in fact no step, and that the reported 0.499 sec step is, in fact, subsequently implemented as a 0.499 sec slew because of the overriding "-x". But until the "ntpq -p" data is available, it's all just guesswork. -Tom _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
