[ntp:questions] Server and Client can't sync

Brian Utterback brian.utterback at sun.com
Tue Oct 30 15:25:01 UTC 2007

Aggie wrote:
> Here's what I want to do:
>   To have NTPD run on VxWorks and Windows. Set VxWorks as the Server
> and Windows as the Client. My Ulitmate goal is the sync these two
> clocks.
> Here's the scenario:
>   Whenever I power cycle VxWorks, it will set the clock to 00:00, Jan
> 1, 1970. It's default. I wrote a simple program and set the clock to a
> more current time, 3:00pm, Oct 29, 2007. And I also did the following
> setting:
> VxWorks: Server, Initial time: 3:00pm, Oct29 2007
> Windows: Client, Inital time: 3:02pm, Oct 29 2007
> We would expect that the clock on Windows would be sync to the one on
> VxWorks after a couple minutes. However, after running ntpd for a
> couple minutes, the clock on Windows was changed to 5:15pm, Nov 21
> 1988. I have no idea why it happened. So I looked at the timestamp
> packet, here's one of the packet from the server to the client:
> Reference clock update Time: Oct 29, 2007 15:17:57.08333 UTC
> Originate Time Stamp: Oct 29, 2007 15:16:42.9551 UTC
> Receive Time Stamp: Jan 1, 1970 00:21:26.0827 UTC
> Transmit Time Stamp: Oct 29, 2007 15:20:30.1500 UTC
> Why am I still getting Jan 1, 1970 as the Receive Time Stamp? Is it
> because my simple program didn't set the clock correctly?? Are there
> more than one clock on a system? Am i supposed to set all of the
> clocks first before I run ntpd?? Thanks.

Hmm. The interesting thing here is that there are two server generated
timestamps in a packet that is sent to the client, namely the receive 
and the transmit timestamp and these two timestamps are clearly from
differing time frames. I suppose that if you did the time change after
ntpd was running you could get this, but you implied that ntpd wasn't
run until after the clock change. True?

If that is true, that would seem to indicate that two different clocks
are being used. Does VxWorks use the SO_TIMESTAMP socket option to get
the timestamp of the incoming packet? Perhaps the SO_TIMESTAMP option
only uses the time since boot and not the wall clock time?

Brian Utterback

More information about the questions mailing list