ntpd (4.2.2p1) stays "synchronized to LOCAL" - NTP

This is a discussion on ntpd (4.2.2p1) stays "synchronized to LOCAL" - NTP ; My ntpd is no longer synchronizing with the servers specified in ntp.conf, and I'm having trouble figuring out why. ntp.conf looks like this: restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: ntpd (4.2.2p1) stays "synchronized to LOCAL"

  1. ntpd (4.2.2p1) stays "synchronized to LOCAL"

    My ntpd is no longer synchronizing with the servers specified in
    ntp.conf, and I'm having trouble figuring out why.

    ntp.conf looks like this:

    restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery
    restrict 127.0.0.1
    restrict -6 ::1
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    server ntppub.tamu.edu
    server ntp1.cs.wisc.edu
    server ntp-2.cso.uiuc.edu
    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /var/lib/ntp/drift
    keys /etc/ntp/keys

    After 58 minutes of uptime, "ntpq -p" shows:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    ntp3.tamu.edu 128.194.254.7 2 u 386 1024 377 25.258 25459.4
    8473.45
    caesar.cs.wisc. 128.105.201.11 2 u 383 1024 377 51.257 25474.1
    8473.20
    ntp-2.gw.uiuc.e 128.174.38.133 2 u 442 1024 377 56.901 16496.2
    8492.19
    *LOCAL(0) .LOCL. 10 l 49 64 377 0.000 0.000
    0.001

    /var/log/messages shows:

    Dec 4 15:38:02 ntpdate[16513]: step time server 128.194.254.9 offset
    14.354204 sec
    Dec 4 15:38:02 ntpd[16517]: ntpd 4.2.2p1@1.1570-o Fri Aug 18 13:04:14
    UTC 2006 (1)
    Dec 4 15:38:02 ntpd[16518]: precision = 1.000 usec
    Dec 4 15:38:02 ntpd[16518]: Listening on interface wildcard,
    0.0.0.0#123 Disabled
    Dec 4 15:38:02 ntpd[16518]: Listening on interface lo, 127.0.0.1#123
    Enabled
    Dec 4 15:38:02 ntpd[16518]: Listening on interface eth0,
    192.168.1.1#123 Enabled
    Dec 4 15:38:02 ntpd[16518]: Listening on interface eth1,
    76.187.xx.xx#123 Enabled
    Dec 4 15:38:02 ntpd[16518]: kernel time sync status 0040
    Dec 4 15:38:02 ntpd[16518]: getaddrinfo: "::1" invalid host address,
    ignored
    Dec 4 15:38:02 ntpd[16518]: frequency initialized 72.808 PPM from
    /var/lib/ntp/drift
    Dec 4 15:41:17 ntpd[16518]: synchronized to LOCAL(0), stratum 10
    Dec 4 15:41:17 ntpd[16518]: kernel time sync enabled 0001

    When ntpd is in this state, the clock loses roughly half a second every
    minute, or about 10 minutes after a day of uptime (!).

    I'm not sure if it's relevant, but I first noticed this problem about a
    month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
    part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
    the system ran ntpd for years without any issues.

    Any idea why this is happening?

    P.S. This is a Pentium III machine running an Intel D815EEA motherboard
    (i815 chipset). Linux 2.6.18.5 kernel.

    --
    Jordan Russell

  2. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Jordan Russell wrote:
    > When ntpd is in this state, the clock loses roughly half a second every
    > minute, or about 10 minutes after a day of uptime (!).


    I think I've narrowed down the cause of this: The Linux kernel
    (2.6.18.5) is actually misdetecting the CPU frequency; it claims the
    processor is running at ~804 MHz when it's really running at ~797 MHz.

    I find that ntpd works fine if I switch away from the default "tsc"
    clocksource to a clocksource not dependent on the CPU frequency being
    detected correctly, e.g. "acpi_pm":

    # echo acpi_pm >
    /sys/devices/system/clocksource/clocksource0/current_clocksource

    --
    Jordan Russell

  3. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Jordan Russell wrote:

    > My ntpd is no longer synchronizing with the servers specified in
    > ntp.conf, and I'm having trouble figuring out why.
    >
    > ntp.conf looks like this:
    >
    > restrict default kod nomodify notrap nopeer noquery
    > restrict -6 default kod nomodify notrap nopeer noquery
    > restrict 127.0.0.1
    > restrict -6 ::1
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    > server ntppub.tamu.edu
    > server ntp1.cs.wisc.edu
    > server ntp-2.cso.uiuc.edu
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /var/lib/ntp/drift
    > keys /etc/ntp/keys
    >
    > After 58 minutes of uptime, "ntpq -p" shows:
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > ntp3.tamu.edu 128.194.254.7 2 u 386 1024 377 25.258 25459.4
    > 8473.45
    > caesar.cs.wisc. 128.105.201.11 2 u 383 1024 377 51.257 25474.1
    > 8473.20
    > ntp-2.gw.uiuc.e 128.174.38.133 2 u 442 1024 377 56.901 16496.2
    > 8492.19
    > *LOCAL(0) .LOCL. 10 l 49 64 377 0.000 0.000
    > 0.001
    >
    > /var/log/messages shows:
    >
    > Dec 4 15:38:02 ntpdate[16513]: step time server 128.194.254.9 offset
    > 14.354204 sec
    > Dec 4 15:38:02 ntpd[16517]: ntpd 4.2.2p1@1.1570-o Fri Aug 18 13:04:14
    > UTC 2006 (1)
    > Dec 4 15:38:02 ntpd[16518]: precision = 1.000 usec
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface wildcard,
    > 0.0.0.0#123 Disabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface lo, 127.0.0.1#123
    > Enabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface eth0,
    > 192.168.1.1#123 Enabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface eth1,
    > 76.187.xx.xx#123 Enabled
    > Dec 4 15:38:02 ntpd[16518]: kernel time sync status 0040
    > Dec 4 15:38:02 ntpd[16518]: getaddrinfo: "::1" invalid host address,
    > ignored
    > Dec 4 15:38:02 ntpd[16518]: frequency initialized 72.808 PPM from
    > /var/lib/ntp/drift
    > Dec 4 15:41:17 ntpd[16518]: synchronized to LOCAL(0), stratum 10
    > Dec 4 15:41:17 ntpd[16518]: kernel time sync enabled 0001
    >
    > When ntpd is in this state, the clock loses roughly half a second every
    > minute, or about 10 minutes after a day of uptime (!).


    How badly does the clock drift if ntpd is not running? If it's still
    ten minutes per day, you either have a severe hardware problem or a
    software problem that is causing your system to lose timer interrupts.

    >
    > I'm not sure if it's relevant, but I first noticed this problem about a
    > month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
    > part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
    > the system ran ntpd for years without any issues.



    Simplify!!! If you don't NEED IP V6, don't mess with it!!! Even if
    you NEED it, debugging should be easier if you can eliminate it temporarily.

    At the time you took your ntpq "banner", your clock appears to have been
    off by something between sixteen and twenty-five seconds. Worse, two
    of your servers have opinions of what time it is that differ by about
    ten seconds; one or both are insane!!!

    Can you add at least one more internet server? Two more would be
    better. A total of five servers allows you to reject two bad ones and
    still have a workable configuration.

    I suspect that your O/S upgrade introduced some bugs. It's hard to
    tell, from here, what or where they might be. Both the O/S and the new
    version of ntpd are suspect at this point.

    Another odd thing is that your poll interval seems locked at 1024
    seconds when, given the humongous offset, I'd expect to see polling at
    64 second intervals. With a polling interval that large, it may take
    weeks to synchronize your clock. Normally we expect to see 1024 second
    polling only when your clock is already very well synchronized.

    You can eliminate the RedHat version of ntpd by downloading the source
    using the links at http://www.ntp.org/, and building from source. If
    that works, your problem is solved. If it doesn't work, I'd say that
    you have either an O/S problem or a hardware problem.

    Good luck.

  4. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    In article ,
    Richard B. Gilbert wrote:
    > Jordan Russell wrote:


    > remote refid st t when poll reach delay offset
    > jitter


    > ntp-2.gw.uiuc.e 128.174.38.133 2 u 442 1024 377 56.901 16496.2
    > 8492.19
    > *LOCAL(0) .LOCL. 10 l 49 64 377 0.000 0.000
    > 0.001


    > Another odd thing is that your poll interval seems locked at 1024
    > seconds when, given the humongous offset, I'd expect to see polling at
    > 64 second intervals. With a polling interval that large, it may take


    The poll interval is 64 seconds. ntpd sets the poll intervals of
    rejected sources to maxpoll. They are being rejected because the jitter
    appears too high, which is a result of the high time slew rate (frequency
    error) causing different samples to vary greatly in offset.

    This also raises the question of why the local clock was configured
    in the first place. If it had not been, ntpd would have correctly
    detected that it was in a hopeless situation and would have reported
    unsynchronised and eventually shut down. In my view, most people shouldn't
    configure the local clock, and those that do should have thought carefully
    about it.

  5. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    david@djwhome.demon.co.uk (David Woolley) writes:

    > In article ,
    > This also raises the question of why the local clock was configured
    > in the first place. If it had not been, ntpd would have correctly
    > detected that it was in a hopeless situation and would have reported
    > unsynchronised and eventually shut down. In my view, most people shouldn't
    > configure the local clock, and those that do should have thought carefully
    > about it.


    Under what circumstances *should* the local clock be configured?

    (Your remark hit a nerve. I recently booted my laptop without network
    access for the first time, and ntp wrote 0.0 into the driftfile. Sounds
    like it wouldn't have done that if the local clock hadn't been
    configured.)

    Jon

  6. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    "Jon KÃ¥re Hellan" wrote in message
    news:1mslfuprbu.fsf@persaunet.uninett.no...
    [...]
    > Under what circumstances *should* the local clock be configured?


    Canonically, 'when it is being disciplined by other means'.

    In practice, when you want your bottleneck host to keep serving time
    even when its Internet connection has (temporarily) failed. That way,
    the entire flock stays with it, which is probably preferable to all
    of them drifting every which way. The expected variation is halved
    immediately; also, an always-on Internet gateway will probably coast
    closer to real time than a herd of laptops.

    Groetjes,
    Maarten Wiltink



  7. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"


    "Jon Kåre Hellan" wrote
    >
    > Under what circumstances *should* the local clock be configured?
    >

    Usually, the local clock is configured on a server only in the case when
    such a server should provide its service to a LAN even if all the
    connections to its upstream servers are lost.

    Karel Sandler



  8. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Jon Kåre Hellan wrote:

    > david@djwhome.demon.co.uk (David Woolley) writes:
    >
    >
    >>In article ,
    >>This also raises the question of why the local clock was configured
    >>in the first place. If it had not been, ntpd would have correctly
    >>detected that it was in a hopeless situation and would have reported
    >>unsynchronised and eventually shut down. In my view, most people shouldn't
    >>configure the local clock, and those that do should have thought carefully
    >>about it.

    >
    >
    > Under what circumstances *should* the local clock be configured?
    >


    Normally the local clock is configured only when the system is serving
    time to other systems and must continue to do so even if it loses its
    connection to its upstream servers.

    It is definitely a clock of last resort; if it were any good at all, why
    would you bother running ntpd??? If ntpd had the clock synchronized
    you have anywhere from a few minutes to a few hours of "holdover" during
    which the time is still close to being correct. In most cases a few
    very definitely means VERY few. If the temperature is tightly
    controlled, clock drift should be minimal, if not, the clock will start
    drifting as soon as the temperature changes.

    A lot of people seem to want to use the local clock to synchronize
    clocks in an isolated network. This can be made to work if you don't
    really care about having the correct time and don't need really tight
    synchronization.

  9. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    We're experiencing exactly the same thing with 4.2.0. We recently
    migrated some servers to SLES10, and since we can't get NTP working
    anymore. No syncing to any outside source. I'd be highly interested if
    you find a solution

    cheers
    Stefan


    Jordan Russell wrote:
    > My ntpd is no longer synchronizing with the servers specified in
    > ntp.conf, and I'm having trouble figuring out why.
    >
    > ntp.conf looks like this:
    >
    > restrict default kod nomodify notrap nopeer noquery
    > restrict -6 default kod nomodify notrap nopeer noquery
    > restrict 127.0.0.1
    > restrict -6 ::1
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    > server ntppub.tamu.edu
    > server ntp1.cs.wisc.edu
    > server ntp-2.cso.uiuc.edu
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /var/lib/ntp/drift
    > keys /etc/ntp/keys
    >
    > After 58 minutes of uptime, "ntpq -p" shows:
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > ntp3.tamu.edu 128.194.254.7 2 u 386 1024 377 25.258 25459.4
    > 8473.45
    > caesar.cs.wisc. 128.105.201.11 2 u 383 1024 377 51.257 25474.1
    > 8473.20
    > ntp-2.gw.uiuc.e 128.174.38.133 2 u 442 1024 377 56.901 16496.2
    > 8492.19
    > *LOCAL(0) .LOCL. 10 l 49 64 377 0.000 0.000
    > 0.001
    >
    > /var/log/messages shows:
    >
    > Dec 4 15:38:02 ntpdate[16513]: step time server 128.194.254.9 offset
    > 14.354204 sec
    > Dec 4 15:38:02 ntpd[16517]: ntpd 4.2.2p1@1.1570-o Fri Aug 18 13:04:14
    > UTC 2006 (1)
    > Dec 4 15:38:02 ntpd[16518]: precision = 1.000 usec
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface wildcard,
    > 0.0.0.0#123 Disabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface lo, 127.0.0.1#123
    > Enabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface eth0,
    > 192.168.1.1#123 Enabled
    > Dec 4 15:38:02 ntpd[16518]: Listening on interface eth1,
    > 76.187.xx.xx#123 Enabled
    > Dec 4 15:38:02 ntpd[16518]: kernel time sync status 0040
    > Dec 4 15:38:02 ntpd[16518]: getaddrinfo: "::1" invalid host address,
    > ignored
    > Dec 4 15:38:02 ntpd[16518]: frequency initialized 72.808 PPM from
    > /var/lib/ntp/drift
    > Dec 4 15:41:17 ntpd[16518]: synchronized to LOCAL(0), stratum 10
    > Dec 4 15:41:17 ntpd[16518]: kernel time sync enabled 0001
    >
    > When ntpd is in this state, the clock loses roughly half a second every
    > minute, or about 10 minutes after a day of uptime (!).
    >
    > I'm not sure if it's relevant, but I first noticed this problem about a
    > month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
    > part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
    > the system ran ntpd for years without any issues.
    >
    > Any idea why this is happening?
    >
    > P.S. This is a Pentium III machine running an Intel D815EEA motherboard
    > (i815 chipset). Linux 2.6.18.5 kernel.
    >
    > --
    > Jordan Russell


  10. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    "Richard B. Gilbert" wrote in message
    news:ILmdnVqD-5g_EOjYnZ2dnUVZ_q-dnZ2d@comcast.com...
    [...]
    > It is definitely a clock of last resort; if it were any good at all,
    > why would you bother running ntpd???


    Isn't it obvious? To find out what goes into ntp.drift. (-:
    With the first-order error out of the way, it isn't so bad.


    > [...] If the temperature is tightly controlled, clock drift should
    > be minimal, if not, the clock will start drifting as soon as the
    > temperature changes.


    I find my attic is a very constant environment. The stack of desktop
    cases, with the gateway in the middle, certainly helps to keep its
    temperature up.

    Groetjes,
    Maarten Wiltink



  11. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Also check out http://ntp.isc.org/Support/TroubleshootingNTP as there may be
    something in either/both the Known Hardware issues and Known OS Issues
    pages.

    H

  12. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Richard B. Gilbert wrote:
    > How badly does the clock drift if ntpd is not running? If it's still
    > ten minutes per day, you either have a severe hardware problem or a
    > software problem that is causing your system to lose timer interrupts.


    Thanks for responding.

    Yes, it turns out the problem had nothing to do with ntpd after all. It
    seems that starting in Linux 2.6.18, the CPU's time stamp counter (TSC)
    is used to keep time. In my case, for some unknown reason, the kernel
    sometimes misdetects the CPU's TSC frequency on boot, resulting in
    severe clock drift that ntpd is unable to correct.

    In case anyone else is afflicted by the same problem, I've managed to
    work around it by adding the following parameter to my kernel command
    line in grub.conf:

    clocksource=acpi_pm

    This tells the kernel to use the ACPI PM timer to keep time instead of
    the CPU's TSC. (From what I understand, the ACPI PM timer is what older
    Linux kernels used by default.)

    --
    Jordan Russell

  13. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    Stefan wrote:
    > We're experiencing exactly the same thing with 4.2.0. We recently
    > migrated some servers to SLES10, and since we can't get NTP working
    > anymore. No syncing to any outside source. I'd be highly interested if
    > you find a solution


    I solved my problem by adding "clocksource=acpi_pm" to the kernel's
    command line (see other post).

    Note, however, that the "clocksource" parameter only exists starting in
    Linux 2.6.18. It looks like older versions had a "clock" parameter that
    performed a similar function.

    --
    Jordan Russell

  14. Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

    It would be Real Helpful if you would add appropriate information about your
    situation to:

    http://ntp.isc.org/Support/KnownOsIssues

    H

+ Reply to Thread