[ntp:questions] Time steping regardless of "-x" slew only option

Tom Smith smith at cag.zko.hp.com
Thu Jun 28 14:24:08 UTC 2007


Paul.Croome at softwareag.com 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




More information about the questions mailing list