NTPD Sync. Problem - NTP

This is a discussion on NTPD Sync. Problem - NTP ; Hello - I have a ntpd process running, but it never seems to update its local time to the primary time server. When I run "ntpq -pn" I get: bash-2.05# ntpq -pn remote refid st t when poll reach delay ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: NTPD Sync. Problem

  1. NTPD Sync. Problem

    Hello -

    I have a ntpd process running, but it never seems to update its local
    time to the primary time server. When I run "ntpq -pn" I get:

    bash-2.05# ntpq -pn
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000
    0.001
    192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000
    0.000

    The system has been running for days like this, and neither server is
    ever prefixed with an "*" indicating the server time is being used.

    I am running this on a linux system which I want to serve time to other
    computers on my local network when the primary time server is
    unavailable. The linux system also should sync its time to the primary
    time server when that computer is available (it won't be always), and
    when it's not available it should serve it's local time to the other
    clients on the network.

    Primary Time Server: 192.168.1.150
    The linux server IP: 192.168.1.161

    Here's my ntp.conf for the linux server:
    server 127.127.1.1
    fudge 127.127.1.1 stratum 16
    server 192.168.1.150
    driftfile /var/lib/ntp/drift
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

    The other clients on the network are able to get time from the linux
    server, but it's serves the local time which is different from the time
    at 192.168.1.150. It never updates it's local time to that of
    192.168.1.150 (primary time server).

    When I run "w32tm /monitor /computers:192.168.1.161" from a windows pc
    on the network I get:
    192.168.1.161 [192.168.1.161]:
    ICMP: 0ms delay.
    NTP: -371.0058478s offset from local clock
    RefID: 'LOCL' [73.78.73.84]

    This at least indicates the linux server responds to ntp requests.

    What am I missing here? ANy help would be greatly appreciated!

    Thanks,

    Garrett


  2. Re: NTPD Sync. Problem

    Garrett wrote:

    > Hello -
    >
    > I have a ntpd process running, but it never seems to update its local
    > time to the primary time server. When I run "ntpq -pn" I get:
    >
    > bash-2.05# ntpq -pn
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > 127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000
    > 0.001
    > 192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000
    > 0.000
    >


    Nothing is EVER going to synchronize to this! Its stratum is 16 which
    is a code that means "I'm not synchronized." In principal, it could
    mean that it is getting time from a stratum 15 server but few, if any,
    servers operate at stratum 15.

    It might, some day, synchronize to 192.168.1.150 but the "reach" field
    shows that 192.168.1.150 has not responded to the last eight queries!!

    > The system has been running for days like this, and neither server is
    > ever prefixed with an "*" indicating the server time is being used.
    >
    > I am running this on a linux system which I want to serve time to other
    > computers on my local network when the primary time server is
    > unavailable. The linux system also should sync its time to the primary
    > time server when that computer is available (it won't be always), and
    > when it's not available it should serve it's local time to the other
    > clients on the network.
    >
    > Primary Time Server: 192.168.1.150
    > The linux server IP: 192.168.1.161
    >
    > Here's my ntp.conf for the linux server:
    > server 127.127.1.1
    > fudge 127.127.1.1 stratum 16


    Don't use stratum 16! No one will ever synch to a server at stratum 16!
    It is conventional to use a high stratum for the local clock when it is
    being used to serve time to clients but stratum 16 is too high. Try 10
    or 12.

    > server 192.168.1.150
    > driftfile /var/lib/ntp/drift
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    >
    > The other clients on the network are able to get time from the linux
    > server, but it's serves the local time which is different from the time
    > at 192.168.1.150. It never updates it's local time to that of
    > 192.168.1.150 (primary time server).
    >
    > When I run "w32tm /monitor /computers:192.168.1.161" from a windows pc
    > on the network I get:
    > 192.168.1.161 [192.168.1.161]:
    > ICMP: 0ms delay.
    > NTP: -371.0058478s offset from local clock
    > RefID: 'LOCL' [73.78.73.84]
    >
    > This at least indicates the linux server responds to ntp requests.
    >
    > What am I missing here? ANy help would be greatly appreciated!
    >


    The basic thing you seem to be missing is that NTP is a hierarchical
    protocol designed to synchronize clocks to UTC. You seem to be trying
    to synchronize clocks without a UTC reference. It's possible but your
    time will be correct only by accident! Your time will be not only
    incorrect but also will drift from day to day.

    Your immediate problem seems to be that your "primary time server" is
    not responding to queries. Either ntpd is not running, there is a
    hardware problem, or you have used misconfigured your primary time
    server. Restrict statements are always a likely suspect in such a case.

    A "normal" NTP subnet would have at least one server getting its time
    from four or five internet servers. That server would be serving time
    to local clients. An alternative configuration would be at least one
    server with a hardware reference clock (GPS Timing Receiver, HF receiver
    tuned to a broadcast such as WWV or CHU (in Canada), JJY (in Japan) or a
    VLF receiver tuned to WWVB (60 KHz), or an atomic clock.)



  3. Re: NTPD Sync. Problem

    On 2006-12-19, Garrett wrote:

    > remote refid st t when poll reach delay offset jitter
    >================================================== ================
    > 127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000 0.001


    ntpd is not using the undisciplined local clock because it is operating
    at Stratum 16. You need to modify your ntp.conf to fix this.

    > 192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000 0.000


    ntpd has been able to establish an association with this server (because
    the refid, stratum and type are set). But, as has been stated elsewhere,
    ntpd has not received an NTP packet from 192.168.1.150 during the last 8
    poll intervals.

    Have you checked the configuration of 192.168.1.150 to ensure that you
    are allowed access?

    192.168.1.150 is claiming to be a Stratum-1 server even though it is
    "synced" to it's undisciplined local clock. This is generally frowned
    upon since it can allow a low quality time source to masquerade as real
    time source.

    > I am running this on a linux system which I want to serve time to other
    > computers on my local network when the primary time server is
    > unavailable.


    Just make sure that the strata of the undisciplined local clocks on both
    time servers is _not_ the same.

    > The linux system also should sync its time to the primary
    > time server when that computer is available (it won't be always), and
    > when it's not available it should serve it's local time to the other
    > clients on the network.


    Please keep in mind that, in this configuration, the ntpd in the .150
    server will be following that system's drifting mother board clock.
    And the .161 server will either be following it's own drifting mother
    board clock _or_ it will be attempting to converge on the .150 server's
    drifting mother board clock. So the clients will be following a moving
    target. Don't expect extremely tight coupling.

    > Primary Time Server: 192.168.1.150
    > The linux server IP: 192.168.1.161
    >
    > Here's my ntp.conf for the linux server:
    > server 127.127.1.1
    > fudge 127.127.1.1 stratum 16


    Change the 16 to 11 or 12.

    > server 192.168.1.150


    Append iburst to this line to speed up synchronization w/ this server.

    > driftfile /var/lib/ntp/drift
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap


    This restrict statement is not breaking anything. But you've left the
    default restriction, for everyone else other than 192.168.1.0/24,
    _less_ restrictive. I'd change this to 'restrict default nomodify
    notrap'.

    > The other clients on the network are able to get time from the linux
    > server,


    The .161 server is unsynchronized. You clients should not be accepting
    time from it.

    > but it's serves the local time which is different from the time
    > at 192.168.1.150.


    The .161 server can't serve time because it is not synchronized.

    > It never updates it's local time to that of 192.168.1.150 (primary
    > time server).


    Check the .150 server configuration.

    If possible, post the .150 server ntp.conf file and 'ntpq -p' billboard
    so that we can see them.

    > What am I missing here?


    Some real sources of time.

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  4. Re: NTPD Sync. Problem

    Thanks to everyone who responded. The server at 192.168.1.150 is
    temporarily using its local clock as well, but this will not be the
    case when this system is deployed.

    I changed the stratum of the 192.168.1.161 local time to 12 as
    suggested. Everything seems happy now.

    Thanks again for your help.

    Cheers,

    Garrett

    Steve Kostecke wrote:
    > On 2006-12-19, Garrett wrote:
    >
    > > remote refid st t when poll reach delay offset jitter
    > >================================================== ================
    > > 127.127.1.1 .LOCL. 16 l 2 64 377 0.000 0.000 0.001

    >
    > ntpd is not using the undisciplined local clock because it is operating
    > at Stratum 16. You need to modify your ntp.conf to fix this.
    >
    > > 192.168.1.150 .LOCL. 1 u 5 64 0 0.000 0.000 0.000

    >
    > ntpd has been able to establish an association with this server (because
    > the refid, stratum and type are set). But, as has been stated elsewhere,
    > ntpd has not received an NTP packet from 192.168.1.150 during the last 8
    > poll intervals.
    >
    > Have you checked the configuration of 192.168.1.150 to ensure that you
    > are allowed access?
    >
    > 192.168.1.150 is claiming to be a Stratum-1 server even though it is
    > "synced" to it's undisciplined local clock. This is generally frowned
    > upon since it can allow a low quality time source to masquerade as real
    > time source.
    >
    > > I am running this on a linux system which I want to serve time to other
    > > computers on my local network when the primary time server is
    > > unavailable.

    >
    > Just make sure that the strata of the undisciplined local clocks on both
    > time servers is _not_ the same.
    >
    > > The linux system also should sync its time to the primary
    > > time server when that computer is available (it won't be always), and
    > > when it's not available it should serve it's local time to the other
    > > clients on the network.

    >
    > Please keep in mind that, in this configuration, the ntpd in the .150
    > server will be following that system's drifting mother board clock.
    > And the .161 server will either be following it's own drifting mother
    > board clock _or_ it will be attempting to converge on the .150 server's
    > drifting mother board clock. So the clients will be following a moving
    > target. Don't expect extremely tight coupling.
    >
    > > Primary Time Server: 192.168.1.150
    > > The linux server IP: 192.168.1.161
    > >
    > > Here's my ntp.conf for the linux server:
    > > server 127.127.1.1
    > > fudge 127.127.1.1 stratum 16

    >
    > Change the 16 to 11 or 12.
    >
    > > server 192.168.1.150

    >
    > Append iburst to this line to speed up synchronization w/ this server.
    >
    > > driftfile /var/lib/ntp/drift
    > > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

    >
    > This restrict statement is not breaking anything. But you've left the
    > default restriction, for everyone else other than 192.168.1.0/24,
    > _less_ restrictive. I'd change this to 'restrict default nomodify
    > notrap'.
    >
    > > The other clients on the network are able to get time from the linux
    > > server,

    >
    > The .161 server is unsynchronized. You clients should not be accepting
    > time from it.
    >
    > > but it's serves the local time which is different from the time
    > > at 192.168.1.150.

    >
    > The .161 server can't serve time because it is not synchronized.
    >
    > > It never updates it's local time to that of 192.168.1.150 (primary
    > > time server).

    >
    > Check the .150 server configuration.
    >
    > If possible, post the .150 server ntp.conf file and 'ntpq -p' billboard
    > so that we can see them.
    >
    > > What am I missing here?

    >
    > Some real sources of time.
    >
    > --
    > Steve Kostecke
    > NTP Public Services Project - http://ntp.isc.org/



+ Reply to Thread