Server and Client can't sync - NTP

This is a discussion on Server and Client can't sync - NTP ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Server and Client can't sync

  1. Server and Client can't sync

    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.


  2. Re: Server and Client can't sync

    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

  3. Re: Server and Client can't sync

    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!

  4. Re: Server and Client can't sync

    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


  5. Re: Server and Client can't sync

    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



  6. Re: Server and Client can't sync

    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.

  7. Re: Server and Client can't sync

    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.

  8. Re: Server and Client can't sync

    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

  9. Re: Server and Client can't sync

    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



  10. Re: Server and Client can't sync

    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

+ Reply to Thread