Problem with xntp after reinstall on openSUSE 10.3 - NTP

This is a discussion on Problem with xntp after reinstall on openSUSE 10.3 - NTP ; Hello, I run a xntp server on Suse 10.0 for the last 2 years. Last week I reinstalled the server using openSUSE 10.3. I setup the server to run chroot (in /etc/sysconfig/ntp) like before and use the same ntp.conf. But ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Problem with xntp after reinstall on openSUSE 10.3

  1. Problem with xntp after reinstall on openSUSE 10.3

    Hello,

    I run a xntp server on Suse 10.0 for the last 2 years. Last week I reinstalled
    the server using openSUSE 10.3. I setup the server to run chroot (in
    /etc/sysconfig/ntp) like before and use the same ntp.conf. But now the time is
    allways wrong after some hours.

    Meanwhile I took all restrict rules out of the file (but I had them in before
    too and it worked for a long time), but still have this problem. This is the
    current ntp.conf I use:


    server 127.127.1.0 # Local clock
    fudge 127.127.1.0 stratum 10 # Local clock is unsynchronized (stratum 10)

    server 0.de.pool.ntp.org iburst prefer
    server 1.de.pool.ntp.org iburst
    server 2.de.pool.ntp.org iburst

    driftfile /var/lib/ntp/drift/ntp.drift
    logfile /var/log/ntp


    About two minutes after starting xntpd:
    # ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 21 64 1 0.000 0.000 3.906
    *213.ip-net02.em 192.53.103.108 2 u 4 64 1 16.846 113.006 48.404
    +www.alter-provi 217.91.44.17 2 u 3 64 1 27.271 147.323 39.202
    +berlin.zq1.de 194.25.115.122 2 u 2 64 1 28.322 121.759 46.183


    About 5 minutes after startup it fall back to local and ntpd shows:
    # ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    *LOCAL(0) .LOCL. 10 l 17 64 37 0.000 0.000 3.906
    213.ip-net02.em 192.53.103.108 2 u 16 64 37 16.435 1247.22 958.049
    www.alter-provi 217.91.44.17 2 u 14 64 37 28.379 1298.52 968.629
    berlin.zq1.de 194.25.115.122 2 u 12 64 37 27.911 1269.07 973.514


    The ntp logfile just says:
    # cat /var/log/ntp
    15 Oct 17:31:09 ntpd[6534]: synchronized to 62.52.175.213, stratum 2
    15 Oct 17:31:09 ntpd[6534]: kernel time sync status change 0001
    15 Oct 17:35:11 ntpd[6534]: synchronized to 85.25.132.119, stratum 2
    15 Oct 17:35:15 ntpd[6534]: synchronized to LOCAL(0), stratum 10


    After 2 days my ntp server has allready a delay to the real time of about 20
    minutes. Any idea why it allways fall back to local? The internet connection
    is allways available.


    Regards
    Marc

  2. Re: Problem with xntp after reinstall on openSUSE 10.3

    Marc Muehlfeld wrote:
    > Hello,
    >
    > I run a xntp server on Suse 10.0 for the last 2 years. Last week I
    > reinstalled the server using openSUSE 10.3. I setup the server to run
    > chroot (in /etc/sysconfig/ntp) like before and use the same ntp.conf.
    > But now the time is allways wrong after some hours.
    >
    > Meanwhile I took all restrict rules out of the file (but I had them in
    > before too and it worked for a long time), but still have this problem.
    > This is the current ntp.conf I use:
    >
    >
    > server 127.127.1.0 # Local clock
    > fudge 127.127.1.0 stratum 10 # Local clock is unsynchronized (stratum
    > 10)
    >
    > server 0.de.pool.ntp.org iburst prefer
    > server 1.de.pool.ntp.org iburst
    > server 2.de.pool.ntp.org iburst
    >
    > driftfile /var/lib/ntp/drift/ntp.drift
    > logfile /var/log/ntp
    >
    >
    > About two minutes after starting xntpd:
    > # ntpq -p
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    >
    > LOCAL(0) .LOCL. 10 l 21 64 1 0.000 0.000
    > 3.906
    > *213.ip-net02.em 192.53.103.108 2 u 4 64 1 16.846 113.006
    > 48.404
    > +www.alter-provi 217.91.44.17 2 u 3 64 1 27.271 147.323
    > 39.202
    > +berlin.zq1.de 194.25.115.122 2 u 2 64 1 28.322 121.759
    > 46.183
    >
    >
    > About 5 minutes after startup it fall back to local and ntpd shows:
    > # ntpq -p
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    >
    > *LOCAL(0) .LOCL. 10 l 17 64 37 0.000 0.000
    > 3.906
    > 213.ip-net02.em 192.53.103.108 2 u 16 64 37 16.435 1247.22
    > 958.049
    > www.alter-provi 217.91.44.17 2 u 14 64 37 28.379 1298.52
    > 968.629
    > berlin.zq1.de 194.25.115.122 2 u 12 64 37 27.911 1269.07
    > 973.514
    >
    >
    > The ntp logfile just says:
    > # cat /var/log/ntp
    > 15 Oct 17:31:09 ntpd[6534]: synchronized to 62.52.175.213, stratum 2
    > 15 Oct 17:31:09 ntpd[6534]: kernel time sync status change 0001
    > 15 Oct 17:35:11 ntpd[6534]: synchronized to 85.25.132.119, stratum 2
    > 15 Oct 17:35:15 ntpd[6534]: synchronized to LOCAL(0), stratum 10
    >
    >
    > After 2 days my ntp server has allready a delay to the real time of
    > about 20 minutes. Any idea why it allways fall back to local? The
    > internet connection is allways available.
    >
    >
    > Regards
    > Marc


    My first guess would be that your local clock is off by more than 500
    Parts Per Million (PPM). 500 PPM is the maximum frequency correction
    that ntpd can make. If the local clock is worse than that your options
    are to:
    a. Live with it.
    b. Get it fixed or adjust it (adjtimex???)

    If you have a drift file, check the value stored in it. Most machines
    will have an absolute value less than 50. If the absolute value is
    substantially greater than 100 you may have a problem with the local
    clock. Ntpd is supposed to be able to cope but I've not yet seen a
    local clock that's off by more than 100 PPM.


    Some Linux (and Windows) systems have been found to "lose" clock
    interrupts. The usual symptom is that ntpd "steps" the clock quite often.


  3. Re: Problem with xntp after reinstall on openSUSE 10.3

    On 2007-10-15, Marc Muehlfeld wrote:

    > I run a xntp server on Suse 10.0 for the last 2 years. Last week I
    > reinstalled the server using openSUSE 10.3.


    Which means that you changed your kernel.

    Your new kernel may require one or more of various command-line options
    to allow ntpd to work with it.

    Or you may need to re-compile your kernel with a lower HZ value.

    Or you may need to recalibrate your tick.

    One procedure for recalibrating your tick is documented at
    http://support.ntp.org/bin/view/Supp...#Section_9.1.6.

    This topic contains links to other methods of adjusting your tick.

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

  4. Re: Problem with xntp after reinstall on openSUSE 10.3

    Richard B. Gilbert schrieb:
    > My first guess would be that your local clock is off by more than 500
    > Parts Per Million (PPM). 500 PPM is the maximum frequency correction
    > that ntpd can make.


    The PPM of current system accoring /var/log/messages: 5.706
    The old logfile showed: 161.758



    > If you have a drift file, check the value stored in it. Most machines
    > will have an absolute value less than 50.


    The drift file of the new system consists: 6.194


  5. Re: Problem with xntp after reinstall on openSUSE 10.3

    Marc,

    first, I've also just upgraded a x86_64 machine to openSUSE 10.3, and see no
    problems using the ntpd version with the distribution.

    Marc Muehlfeld wrote:
    > Richard B. Gilbert wrote:
    >> My first guess would be that your local clock is off by more than 500
    >> Parts Per Million (PPM). 500 PPM is the maximum frequency correction
    >> that ntpd can make.

    >
    > The PPM of current system accoring /var/log/messages: 5.706
    > The old logfile showed: 161.758
    >
    >
    >
    >> If you have a drift file, check the value stored in it. Most machines
    >> will have an absolute value less than 50.

    >
    > The drift file of the new system consists: 6.194


    This seems to indicate that the new kernel implements the system clock based
    on a different timer API than the old kernel. That new timer API may not
    support the particular chipset on your mainboard correctly.

    As a test, you might stop ntpd, then set the system time manually running

    date -u; ntpdate ptbtime1.ptb.de

    Then let the system time freewheeling, and run

    date -u; ntpdate -q ptbtime1.ptb.de

    in some intervals. The latter command use "-q" to query only. It does not
    set your system time, but reports the difference between the remote NTP
    server and your system clock. Please report whether the difference is
    growing slow or fast.

    BTW, while using the pool servers as you have done is generally the
    preferable way to run ntpd, for this particular test you should use a
    dedicated server like one of the PTB servers in order to yield more
    comparable results.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  6. Re: Problem with xntp after reinstall on openSUSE 10.3

    Martin Burnicki schrieb:
    > As a test, you might stop ntpd, then set the system time manually running


    # date -u; ntpdate ptbtime1.ptb.de
    Di 16. Okt 09:08:09 UTC 2007
    16 Oct 11:08:13 ntpdate[2586]: step time server 192.53.103.108 offset 3.867615 sec



    > Then let the system time freewheeling, and run


    # date -u; ntpdate -q ptbtime1.ptb.de
    Di 16. Okt 09:17:12 UTC 2007
    server 192.53.103.108, stratum 1, offset 2.711909, delay 0.06961
    16 Oct 11:17:12 ntpdate[2927]: step time server 192.53.103.108 offset 2.711909 sec

    # date -u; ntpdate -q ptbtime1.ptb.de
    Di 16. Okt 09:33:04 UTC 2007
    server 192.53.103.108, stratum 1, offset 7.275004, delay 0.06960
    16 Oct 11:33:04 ntpdate[3562]: step time server 192.53.103.108 offset 7.275004 sec



    > Please report whether the difference is growing slow or fast.


    As you can see, it it growing fast (more than 7 sec in 20 minutes)

  7. Re: Problem with xntp after reinstall on openSUSE 10.3

    Martin Burnicki schrieb:
    > This seems to indicate that the new kernel implements the system clock based
    > on a different timer API than the old kernel. That new timer API may not
    > support the particular chipset on your mainboard correctly.


    Would it be a solution to run the ntp server on a different machine with
    different chipset and let the current one just be a ntp client. And the ntp
    drift technique could get to come to grips with it and it will run fine in future?

  8. Re: Problem with xntp after reinstall on openSUSE 10.3

    Marc Muehlfeld wrote:
    > Martin Burnicki schrieb:
    >> This seems to indicate that the new kernel implements the system clock
    >> based on a different timer API than the old kernel. That new timer API
    >> may not support the particular chipset on your mainboard correctly.

    >
    > Would it be a solution to run the ntp server on a different machine with
    > different chipset and let the current one just be a ntp client. And the
    > ntp drift technique could get to come to grips with it and it will run
    > fine in future?


    I'm afraid that would not solve the problem. Every NTP node is primarily a
    NTP client which gets its time from an upstream time source, which can be
    another NTP server, a radio clock or GPS receiver, or whatever.

    Using that time source it disciplines its own system time, which can then be
    made available to other NTP nodes on the network.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: Problem with xntp after reinstall on openSUSE 10.3

    Marc Muehlfeld wrote:
    > Martin Burnicki schrieb:
    >> As a test, you might stop ntpd, then set the system time manually running

    >
    > # date -u; ntpdate ptbtime1.ptb.de
    > Di 16. Okt 09:08:09 UTC 2007
    > 16 Oct 11:08:13 ntpdate[2586]: step time server 192.53.103.108 offset
    > 3.867615 sec
    >
    >
    >
    >> Then let the system time freewheeling, and run

    >
    > # date -u; ntpdate -q ptbtime1.ptb.de
    > Di 16. Okt 09:17:12 UTC 2007
    > server 192.53.103.108, stratum 1, offset 2.711909, delay 0.06961
    > 16 Oct 11:17:12 ntpdate[2927]: step time server 192.53.103.108 offset
    > 2.711909 sec
    >
    > # date -u; ntpdate -q ptbtime1.ptb.de
    > Di 16. Okt 09:33:04 UTC 2007
    > server 192.53.103.108, stratum 1, offset 7.275004, delay 0.06960
    > 16 Oct 11:33:04 ntpdate[3562]: step time server 192.53.103.108 offset
    > 7.275004 sec
    >
    >
    >
    > > Please report whether the difference is growing slow or fast.

    >
    > As you can see, it it growing fast (more than 7 sec in 20 minutes)


    Oops, that's too much. Maybe the adjtimex tool can help to decrease the
    initial drift to an acceptable value.

    Unfortunately I'm not familiar with adjtimex since I haven't had to use it,
    yet. Maybe you should search the archive of this group (just google ...),
    or someone else might jump in here ...

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  10. Re: Problem with xntp after reinstall on openSUSE 10.3

    got the same thing in SLES9 SP3 !

+ Reply to Thread