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

In article <1193698184.474071.249360@i13g2000prf.googlegroups. com>,
Aggie wrote:

> To have NTPD run on VxWorks and Windows. Set VxWorks as the Server

> 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

> 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

I don't have the VxWorks knowledge (few if any on the newsgroup do) to
understand why the receive and transmit timestamps are wildly different
when you didn't change the clock between them, however, if you are really
running ntpd on Windows, because the delay was huge and negative, it
should not have stepped the time. If it really is ntpd, maybe there is
a bug in that it doesn't use the absolute magnitude of root distance to
decide to reject a source. A minus eighteen years delay really
shouldn't be accepted!

On Oct 30, 4:01 pm, da...@ex.djwhome.demon.co.uk.invalid (David
Woolley) wrote:
> In article <1193698184.474071.249...@i13g2000prf.googlegroups. com>,
>
> Aggie wrote:
> > To have NTPD run on VxWorks and Windows. Set VxWorks as the Server
> > 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
> > 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
>
> I don't have the VxWorks knowledge (few if any on the newsgroup do) to
> understand why the receive and transmit timestamps are wildly different
> when you didn't change the clock between them, however, if you are really
> running ntpd on Windows, because the delay was huge and negative, it
> should not have stepped the time. If it really is ntpd, maybe there is
> a bug in that it doesn't use the absolute magnitude of root distance to
> decide to reject a source. A minus eighteen years delay really
> shouldn't be accepted!

But the weird thing is: NTPD will adjust the time on the client half
way between the server and 1970 Jan 1. For example, if the clock on my
server is in 2000, then the clock on the client will be set to 1985.
I have no idea what's going on. Any input would help.

Kevin

Aggie wrote:
[]
> But the weird thing is: NTPD will adjust the time on the client half
> way between the server and 1970 Jan 1. For example, if the clock on my
> server is in 2000, then the clock on the client will be set to 1985.
> I have no idea what's going on. Any input would help.
>
> Kevin

Precisely which version of NTP on Windows is doing this?

David

In article <1193788202.453849.113950@q5g2000prf.googlegroups.c om>,
Aggie wrote:

> But the weird thing is: NTPD will adjust the time on the client half
> way between the server and 1970 Jan 1. For example, if the clock on my

What is weird is that the reply from your server is accepted. Once it
is accepted, nearly -19 years is the correct adjustment, according to the
formula that NTP uses to compensate for processing and propagation
delays.

You will, I think, find that ntpq peers shows a delay and offset both of
which are about 19 years in magnitude. If you cannot
run ntpq peers against the Windows server, other than as a result of
restrict lines, you probably aren't using ntpd, so the bug report will
have to go to someone else.

In article <1193788202.453849.113950@q5g2000prf.googlegroups.c om>,
Aggie wrote:

> But the weird thing is: NTPD will adjust the time on the client half
> way between the server and 1970 Jan 1. For example, if the clock on my

PS. Unless you have explicitly disabled the feature, either for the first
setting, or unconditionally, the real ntpd should abort rather than stepping
more than 1000 seconds.

David Woolley wrote:

> In article <1193788202.453849.113950@q5g2000prf.googlegroups.c om>,
> Aggie wrote:
>
>> But the weird thing is: NTPD will adjust the time on the client half
>> way between the server and 1970 Jan 1. For example, if the clock on my
>
> PS. Unless you have explicitly disabled the feature, either for the first
> setting, or unconditionally, the real ntpd should abort rather than
> stepping more than 1000 seconds.

.... unless the -g option has been given on ntpd's command line, which
allowed a large initial offset.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Brian:
Yes, ntpd wasn't run until after the clock change.

David:
I'm using ntp-dev-4.2.5p83.tar.gz

David:
I'm using option -g, so i can step more than 1000s.

Dear all,
I modified the ntp_io.c and undefine HAVE_TIMESTAMP and
USE_TIMESTAMP_CMSG by adding #if 0, like the following:


/*#if defined(SO_TIMESTAMP) && defined(SCM_TIMESTAMP) */
#if 0
#if defined(CMSG_FIRSTHDR)
#define HAVE_TIMESTAMP
#define USE_TIMESTAMP_CMSG
#ifndef TIMESTAMP_CTLMSGBUF_SIZE
#define TIMESTAMP_CTLMSGBUF_SIZE 1536 /* moderate default */
#endif

After I undefined them, the time on windows is able to sync with the
one on vxworks. Why is this??
I'm really confused on the timestamping thing used in NTP. What layer
are we actually doing the timestamp? Are we doing it on the physical
layer or application layer of the OSI stack? My coworker said if we
undefine HAVE_TIMESTAMP and USE_TIMESTAMP_CMSG, we are going to do the
timestamp on the application, but if we define them, we are actually
doing the timestamp on the physical layer, is that true??

Thanks you very much,
Kevin

David,

Martin Burnicki wrote:
> David Woolley wrote:
>
>> In article <1193788202.453849.113950@q5g2000prf.googlegroups.c om>,
>> Aggie wrote:
>>
>>> But the weird thing is: NTPD will adjust the time on the client half
>>> way between the server and 1970 Jan 1. For example, if the clock on my
>>
>> PS. Unless you have explicitly disabled the feature, either for the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> first setting, or unconditionally, the real ntpd should abort rather than
>> stepping more than 1000 seconds.
>
> ... unless the -g option has been given on ntpd's command line, which
> allowed a large initial offset.

It seems I've read your reply too fast and overseen the details of your
reply. Sorry for that.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany