NTP stratum problem - NTP

This is a discussion on NTP stratum problem - NTP ; Hello, We have solris stations with ntp 4.2, act as a server and clients. These Solaris clients act as peers when the server is down. We have Vxworks machines polling these Solaris clients using VxWorks SntpTimeGet command. This setup works ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: NTP stratum problem

  1. NTP stratum problem

    Hello,

    We have solris stations with ntp 4.2, act as a server and clients.
    These Solaris clients act as peers when the server is down. We have
    Vxworks machines polling these Solaris clients using VxWorks
    SntpTimeGet command.
    This setup works fine, except vxworks machines do not get ntp synced
    from solaris clients, when the server is down. ( When the solaris
    clients boot up - Ntp server is down). This problem does not happen if
    ntp server goes down once solaris clients get synced initially to the
    ntp server.

    >From TCPDUMP, we found that solris clients send stratum 0 to vxworks,

    when they do not get synced to the ntp server( initially), vxworks does
    not accept ntp messages with stratum set to Zero.

    Is there a way to set clients statum to non zero value, before clients
    get synced to the ntp server?

    Our config file is:
    tinker stepout 20
    server 10.2.10.70 prefer burst minpoll 4 maxpoll 6
    server 10.2.10.71 burst minpoll 4 maxpoll 6


    peer 10.2.10.21
    peer 10.2.10.22

    broadcast 224.0.0.1 ttl 4

    enable auth monitor

    ......


    thanks, -andu


  2. Re: NTP stratum problem

    wicks wrote:

    > Hello,
    >
    > We have solris stations with ntp 4.2, act as a server and clients.
    > These Solaris clients act as peers when the server is down. We have
    > Vxworks machines polling these Solaris clients using VxWorks
    > SntpTimeGet command.
    > This setup works fine, except vxworks machines do not get ntp synced
    > from solaris clients, when the server is down. ( When the solaris
    > clients boot up - Ntp server is down). This problem does not happen if
    > ntp server goes down once solaris clients get synced initially to the
    > ntp server.
    >
    >>From TCPDUMP, we found that solris clients send stratum 0 to vxworks,

    > when they do not get synced to the ntp server( initially), vxworks does
    > not accept ntp messages with stratum set to Zero.
    >
    > Is there a way to set clients statum to non zero value, before clients
    > get synced to the ntp server?
    >
    > Our config file is:
    > tinker stepout 20
    > server 10.2.10.70 prefer burst minpoll 4 maxpoll 6
    > server 10.2.10.71 burst minpoll 4 maxpoll 6
    >


    You should probably be using "iburst" instead of "burst". "burst" is a
    special purpose hack used, I believe, dialup internet connections.

    "iburst" says to send the first eight queries at two second intervals.
    It is used to get enough information to start synchronizing the clock in
    about sixteen seconds instead of about 5 and a half minutes.

    You also should probably NOT be specifying minpoll and maxpoll. Ntpd is
    designed select an appropriate polling interval from the default range
    of 6 to 10; it is rare to encounter a situation where something else
    will work better.

    I believe that "stratum 0" means "I am not synchronized" and clients are
    quite correct in refusing to accept time from an unsynchronized system.

    You can add lines like:
    #
    # Declare the local clock to be the clock of last resort.
    # It will be used to serve time in the absence of any other.
    #
    server 127.127.1.0 # Local clock, unit 0
    fudge 127.127.1.0 stratum 10

    Setting the stratum to 10 when serving the unsynchronized local clock is
    conventional and makes it unlikely that ANYONE will use such a server
    unless there is nothing else available.

  3. Re: NTP stratum problem


    Richard B. Gilbert wrote:

    > wicks wrote:
    >
    > > Hello,
    > >
    > > We have solris stations with ntp 4.2, act as a server and clients.
    > > These Solaris clients act as peers when the server is down. We have
    > > Vxworks machines polling these Solaris clients using VxWorks
    > > SntpTimeGet command.
    > > This setup works fine, except vxworks machines do not get ntp synced
    > > from solaris clients, when the server is down. ( When the solaris
    > > clients boot up - Ntp server is down). This problem does not happen if
    > > ntp server goes down once solaris clients get synced initially to the
    > > ntp server.
    > >
    > >>From TCPDUMP, we found that solris clients send stratum 0 to vxworks,

    > > when they do not get synced to the ntp server( initially), vxworks does
    > > not accept ntp messages with stratum set to Zero.
    > >
    > > Is there a way to set clients statum to non zero value, before clients
    > > get synced to the ntp server?
    > >
    > > Our config file is:
    > > tinker stepout 20
    > > server 10.2.10.70 prefer burst minpoll 4 maxpoll 6
    > > server 10.2.10.71 burst minpoll 4 maxpoll 6
    > >

    >
    > You should probably be using "iburst" instead of "burst". "burst" is a
    > special purpose hack used, I believe, dialup internet connections.
    >
    > "iburst" says to send the first eight queries at two second intervals.
    > It is used to get enough information to start synchronizing the clock in
    > about sixteen seconds instead of about 5 and a half minutes.
    >
    > You also should probably NOT be specifying minpoll and maxpoll. Ntpd is
    > designed select an appropriate polling interval from the default range
    > of 6 to 10; it is rare to encounter a situation where something else
    > will work better.
    >
    > I believe that "stratum 0" means "I am not synchronized" and clients are
    > quite correct in refusing to accept time from an unsynchronized system.
    >
    > You can add lines like:
    > #
    > # Declare the local clock to be the clock of last resort.
    > # It will be used to serve time in the absence of any other.
    > #
    > server 127.127.1.0 # Local clock, unit 0
    > fudge 127.127.1.0 stratum 10
    >
    > Setting the stratum to 10 when serving the unsynchronized local clock is
    > conventional and makes it unlikely that ANYONE will use such a server
    > unless there is nothing else available.


    Yes. It did work. Thanks


+ Reply to Thread