Stuck at stratum 16 - NTP

This is a discussion on Stuck at stratum 16 - NTP ; I cannot seem to get my server to out of stratum 16. Are offsets and jitters over 1000 common? Is the offset and jitter in milliseconds? I've let it sit for an hour and it makes no difference. It is ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Stuck at stratum 16

  1. Stuck at stratum 16

    I cannot seem to get my server to out of stratum 16. Are offsets and
    jitters over 1000 common? Is the offset and jitter in milliseconds?

    I've let it sit for an hour and it makes no difference. It is still at
    stratum 16.

    Here is the ps -ef

    00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 112:122 -g

    Thanks,
    Charles


    Below are my ntpq results:


    assID=0 status=c035 sync_alarm, sync_unspec, 3 events, event_clock_reset,
    version="ntpd 4.2.4p0@1.1472-o Thu Oct 4 22:22:31 UTC 2007 (1)",
    processor="x86_64", system="Linux/2.6.22-14-generic", leap=11,
    stratum=16, precision=-20, rootdelay=0.000, rootdispersion=3.855,
    peer=0, refid=STEP,
    reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, poll=4,
    clock=cb65a48a.76969aea Tue, Feb 19 2008 13:55:06.463, state=4,
    offset=0.000, frequency=-3.972, jitter=80.189, noise=0.001,
    stability=0.000, tai=0
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    slice-gw.warnet 18.26.4.105 2 u 49 64 17 32.101 3176.46
    2139.56
    unlawful.id.au 129.6.15.28 2 u 19 64 17 64.230 1662.04
    1386.83
    tesla.fireduck. 63.192.96.10 2 u 16 64 17 24.210 753.143
    2096.85
    server1-a.your. 64.202.112.75 2 u 13 64 17 22.021 1804.17
    1369.11
    leconte.local .STEP. 16 u - 64 0 0.000 0.000
    0.000


    And here is my ntp.conf
    ---------------------------------------
    # /etc/ntp.conf, configuration for ntpd

    driftfile /var/lib/ntp/ntp.drift

    # Enable this if you want statistics to be logged.
    #statsdir /var/log/ntpstats/

    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable


    # You do need to talk to an NTP server or two (or three).

    server 0.north-america.pool.ntp.org iburst
    server 1.north-america.pool.ntp.org iburst
    server 2.north-america.pool.ntp.org iburst
    server 3.north-america.pool.ntp.org iburst

    #server us.pool.ntp.org iburst
    #server ca.pool.ntp.org iburst
    #server pool.ntp.org iburst
    #server ntp.ubuntu.com iburst


    # Fudging if outside servers are down
    server 10.2.5.10
    fudge 10.2.5.10 stratum 10

    #fudge 10.2.5.10 stratum 5
    broadcastdelay 0.008

  2. Re: Stuck at stratum 16

    Charles Leeds wrote:
    > I cannot seem to get my server to out of stratum 16. Are offsets and
    > jitters over 1000 common? Is the offset and jitter in milliseconds?
    >
    > I've let it sit for an hour and it makes no difference. It is still at
    > stratum 16.
    >


    >
    > assID=0 status=c035 sync_alarm, sync_unspec, 3 events, event_clock_reset,


    This and the reachability figures indicate that the clock has recently
    stepped.

    > offset=0.000, frequency=-3.972, jitter=80.189, noise=0.001,


    Frequency <> 0 indicates that at some time the system has been
    synchronized (possibly in a previous run).

    > stability=0.000, tai=0
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > slice-gw.warnet 18.26.4.105 2 u 49 64 17 32.101 3176.46
    > 2139.56


    Reachability 17 indicates that the last time reset was about 4 poll
    intervals ago, which looks like about five minutes ago.

    > unlawful.id.au 129.6.15.28 2 u 19 64 17 64.230 1662.04
    > 1386.83
    > tesla.fireduck. 63.192.96.10 2 u 16 64 17 24.210 753.143
    > 2096.85
    > server1-a.your. 64.202.112.75 2 u 13 64 17 22.021 1804.17
    > 1369.11


    These offsets are all over the place. With delays in this range, you
    would expect the offsets to be within a few 10s of milliseconds of each
    other. Something is badly wrong here. Although you haven't run rv on
    the individual associations, to get their root delays, I think it is
    very likely that no two clocks have overlapping error bands, so they are
    all being rejected as falsetickers.

    Even if you assume the offsets are proportional to age, which you might
    get if the clock frequency was completely broken, they are still all
    over the place

    > leconte.local .STEP. 16 u - 64 0 0.000 0.000
    > 0.000
    >


    I hope this isn't the subject machine itself; that would indicate that
    you had probably broken the loop detection. Otherwise, it is in similar
    difficulties.

    >
    >
    > # Fudging if outside servers are down
    > server 10.2.5.10
    > fudge 10.2.5.10 stratum 10


    Fudge is ineffective here, only reference clocks can be fudged. In any
    case, that server seems to have its own problems.

    >
    > #fudge 10.2.5.10 stratum 5
    > broadcastdelay 0.008


+ Reply to Thread