[ntp:questions] W32Time/CoBox/Spectracom 1 second jumps

Chris Winstanley cnw at zoom.co.uk
Mon Nov 29 16:32:40 UTC 2004


I've inherited the following system:
- a Spectracom Model 8183 Netclock/GPS;
- a Lantronix CoBox-NTP-E1;
- a Windows 2000 server.

The Netclock feeds the CoBox via a serial connection using Format 2.
The Netclock is configured to output Format 2 continuously once per

The Windows 2000 server uses W32Time to synchronise with the CoBox.
W32Time has been configured via the registry to log when it
synchronises and log the magnitude of adjustment made (reported as
either < 0.5 seconds or > 0.5 seconds).

>From the event log and another application that timestamps a data
stream to sub-second accuracy on the server we have noticed that the
occasionally W32Time applies an adjustment of minus 1 second and then
the next time it synchronises applies an adjustment of plus 1 second,
seemingly correcting the previous adjustment.

Having noticed this behaviour we monitored the NTP packets over
ethernet using Ethereal. At the time of the jumps we found that the
reference timestamp and transmit timestamp of the NTP message from the
CoBox to the Windows Server showed a time 1 second less than the
originate timestamp (i.e. the time on the Window 2000 server). The
timestamps placed on the messages by Ethereal indicate that time
between updates from the CoBox are 1 second greater than the time
between transmit timestamps contained within the updates, i.e.
ethereal appears to agree with the Window 2000 server in terms of the
relative amount of time that has passed between updates.

The NTP message from the server to the CoBox reports Reference Clock
Id of "Unidentified Reference Source", a Peer Clock Precision of
"1.0000sec", a Peer Clock Stratum of "unspecified or unavailable" and
a Peer Polling Interval of "invalid (3)".

Originally W32Time was configured to synchronise once a minute which
seems a bit drastic although does seem to fall within the prescribed
limits of the protocol. We have since slowed the polling rate down but
have not had chance to monitor the packets again to check its effect.
However, with the slowed polling rate we still see the 1 second jumps.

I'm no NTP expert but I'm suspicious of:
- the fact that the Netclock outputs the time once a second to the
CoBox - surely the CoBox keeps time inbetween updates?
- the fact that the precision of the Windows 2000 Server clock appears
to be 1.0000sec - surely even a Wintel platform is better than this?

Does anybody have any ideas what could be causing this behaviour?


More information about the questions mailing list