slowly gaining time - NTP

This is a discussion on slowly gaining time - NTP ; The main problem is that ntpd doesn't keep the time updated. Why is it talking to 192.168.1.1? That is my router. 192.168.1.110 is the Linux box that I want to keep updated with ntp. receive: at 65 192.168.1.110 transmit: at ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: slowly gaining time

  1. slowly gaining time

    The main problem is that ntpd doesn't keep the time updated.

    Why is it talking to 192.168.1.1?
    That is my router.

    192.168.1.110 is the Linux box that I want to keep updated with ntp.

    receive: at 65 192.168.1.110<-192.168.1.1 mode 3 code 2
    transmit: at 65 192.168.1.110->192.168.1.1 mode 4

    # ntpq -pn
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    64.235.218.180 209.87.233.53 3 u 674 1024 377 107.280 -205399
    513002.
    216.46.5.9 132.246.168.148 3 u 671 1024 377 108.457 -205547
    512484.
    192.135.48.21 128.138.140.44 2 u 663 1024 377 53.561 -205949
    512504.

    Hours later, still not synced time (*)?
    # ntpq -pn
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    64.235.218.180 128.100.100.128 3 u 764 1024 377 108.422 -163990
    512003.
    216.46.5.9 132.246.168.148 3 u 770 1024 377 110.377 -163960
    511482.
    192.135.48.21 128.138.140.44 2 u 1784 1024 376 51.116 -158890
    512002.

    # more /etc/ntp.conf
    # A pool of public servers. These are taken from all over the world
    # so using one of
    # server europe.pool.ntp.org
    # server us.pool.ntp.org
    # server asia.pool.ntp.org
    # three times may be a better option depending on where you live.
    #
    # See http://www.pool.ntp.org for more information about the project.
    # server 0.pool.ntp.org
    # server 1.pool.ntp.org
    # server 2.pool.ntp.org

    driftfile /var/lib/ntp/ntp.drift

    server 0.ca.pool.ntp.org
    server 1.ca.pool.ntp.org
    server 2.ca.pool.ntp.org


    # more /var/lib/ntp/ntp.drift
    0.000

  2. Re: slowly gaining time

    On 2006-12-23, Jammer wrote:

    > The main problem is that ntpd doesn't keep the time updated.




    > # more /var/lib/ntp/ntp.drift
    > 0.000


    This is likely the problem. Please try deleting this file and restarting
    ntpd. You may wish to make the change suggested below, too.



    > #/etc/ntp.conf
    >
    > driftfile /var/lib/ntp/ntp.drift
    >
    > server 0.ca.pool.ntp.org
    > server 1.ca.pool.ntp.org
    > server 2.ca.pool.ntp.org


    Append iburst to those server lines to speed up ntpd's initial
    synchronization from ~ 8 minutes to 15-30 seconds.

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

  3. Re: slowly gaining time

    With jitter that high you will never sync.

    I suspect either hardware or OS problems (and possibly BIOS settings).

    Please see http://ntp.isc.org/Support/TroubleshootingNTP .

    H

  4. Re: slowly gaining time

    Harlan Stenn wrote:
    > With jitter that high you will never sync.
    >
    > I suspect either hardware or OS problems (and possibly BIOS settings).
    >
    > Please see http://ntp.isc.org/Support/TroubleshootingNTP .
    >
    > H


    I deleted the driftfile and added iburst.

    Jitter gets worse. :-(
    I did these very close together.
    The URL does not provide help for hardware or OS problems. :-(

    ~# ntpq -np
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    208.97.105.139 .INIT. 16 u - 512 0 0.000 0.000
    4000.00
    208.97.105.139 130.126.24.44 3 u 200 256 17 37.599 -550886
    51001.9
    216.168.105.34 207.106.24.162 3 u 180 256 17 55.815 -616325
    62567.9

    # ntpq -np
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    208.97.105.139 .INIT. 16 u - 1024 0 0.000 0.000
    4000.00
    208.97.105.139 130.126.24.44 3 u 17 512 37 37.599 -550886
    106701.
    216.168.105.34 207.106.24.162 3 u 105 512 37 55.815 -616325
    92700.4

  5. Re: slowly gaining time

    Harlan Stenn wrote:
    > With jitter that high you will never sync.
    >
    > I suspect either hardware or OS problems (and possibly BIOS settings).
    >
    > Please see http://ntp.isc.org/Support/TroubleshootingNTP .
    >
    > H

    The internal clock keeps time.
    I set only "server localhost"

  6. Re: slowly gaining time

    Jammer wrote:
    > Harlan Stenn wrote:
    >> With jitter that high you will never sync.
    >>
    >> I suspect either hardware or OS problems (and possibly BIOS settings).
    >>
    >> Please see http://ntp.isc.org/Support/TroubleshootingNTP .
    >>
    >> H

    > The internal clock keeps time.
    > I set only "server localhost"


    The internal clock keeps time IF I do NOT run ntpd.

    # ntpq -np
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    127.0.0.1 .INIT. 16 l - 1024 0 0.000 0.000
    4000.00


    Running ntpd causes the machine to gain time. :-(

  7. Re: slowly gaining time

    On 2006-12-23, Jammer wrote:

    > Harlan Stenn wrote:
    >
    >> I suspect either hardware or OS problems (and possibly BIOS
    >> settings).
    >>
    >> Please see http://ntp.isc.org/Support/TroubleshootingNTP .

    >
    > I deleted the driftfile and added iburst. Jitter gets worse. I did
    > these very close together.


    Did you restart ntpd after making those changes?

    > The URL does not provide help for hardware or OS problems. :-(


    The first two links in the "TOC" at the URL are:

    # 9.1. Known Hardware Issues
    # 9.2. Known Operating System Issues

    Please tell us what hardware, OS, ntpd and kernel version you're using.

    Is this machine using ACPI or APM?

    Do you see any ntpd related messages in your syslog (such as repeated
    time resets)?

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

  8. Re: slowly gaining time

    Steve Kostecke wrote:
    > On 2006-12-23, Jammer wrote:
    >
    >> Harlan Stenn wrote:
    >>
    >>> I suspect either hardware or OS problems (and possibly BIOS
    >>> settings).
    >>>
    >>> Please see http://ntp.isc.org/Support/TroubleshootingNTP .

    >> I deleted the driftfile and added iburst. Jitter gets worse. I did
    >> these very close together.

    >
    > Did you restart ntpd after making those changes?
    >
    >> The URL does not provide help for hardware or OS problems. :-(

    >
    > The first two links in the "TOC" at the URL are:
    >
    > # 9.1. Known Hardware Issues
    > # 9.2. Known Operating System Issues


    I missed that.
    I have a Linux-2.6.19.1 kernel so nuff said. :-)


    > Please tell us what hardware, OS, ntpd and kernel version you're using.


    kernel: ALI15X3: chipset revision 193

    I don't know the exact hardware, something old. :-)


    > Is this machine using ACPI or APM?


    kernel: ACPI: Power Button (FF) [PWRF]
    kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])

    >
    > Do you see any ntpd related messages in your syslog (such as repeated
    > time resets)?
    >


  9. Re: slowly gaining time

    On 2006-12-22, Jammer wrote:

    > Jammer wrote:
    >
    >> The internal clock keeps time. I set only "server localhost"




    > # ntpq -np
    > remote refid st t when poll reach delay offset jitter
    >================================================== =================
    > 127.0.0.1 .INIT. 16 l - 1024 0 0.000 0.000 4000.00


    You've told ntpd to poll (i.e. get the time from) its self. That's not
    going to do you any good.

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

  10. Re: slowly gaining time

    Steve Kostecke wrote:
    > On 2006-12-22, Jammer wrote:
    >
    >> Jammer wrote:
    >>
    >>> The internal clock keeps time. I set only "server localhost"

    >
    >
    >
    >> # ntpq -np
    >> remote refid st t when poll reach delay offset jitter
    >> ================================================== =================
    >> 127.0.0.1 .INIT. 16 l - 1024 0 0.000 0.000 4000.00

    >
    > You've told ntpd to poll (i.e. get the time from) its self. That's not
    > going to do you any good.
    >

    It should do nothing. :-)
    It turns out my clock my have problems without ntpd running. :-(

  11. Re: slowly gaining time

    >>> In article <2f7ec$458cc54c$d8a876c1$31035@NEXICOM.NET>, Jammer writes:

    Jammer> It turns out my clock my have problems without ntpd running. :-(

    Not surprising.

    The information at the subtopics of the URL I posted should still be of
    help.

    H

  12. Re: slowly gaining time

    On 2006-12-23, Jammer wrote:

    > Steve Kostecke wrote:
    >
    >> Please tell us what hardware, OS, ntpd and kernel version you're
    >> using.

    >
    > I have a Linux-2.6.19.1 kernel so nuff said. :-)


    If you google for 2.6.19+ntpd you'll find some problem reports.

    It is possible that your kernel timer interrupt runs at something
    other than 100 Hz. This can cause problems for ntpd. You will need to
    recompile your kernel to change this setting. The default MZ setting is
    in /kernel/Kconfig.hz in the 2.6.19 source tree.

    >> Is this machine using ACPI or APM?

    >
    > kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])


    Changes to your CPU frequency can greatly affect ntpd.

    Does passing NOACPI as a (boot time) kernel argument help?

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

+ Reply to Thread