Stability problem on PowerEdge (SuSE 9.3) - NTP

This is a discussion on Stability problem on PowerEdge (SuSE 9.3) - NTP ; Hi there, i try to settle some time accuracy in our office environment... Our main server is running SuSE 9.3 on AMD64. I installed the xntp package from SuSE (Vers. 4.2.0a-35). Hardware: DELL Power Edge 2850 uanme -a: Linux office ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Stability problem on PowerEdge (SuSE 9.3)

  1. Stability problem on PowerEdge (SuSE 9.3)

    Hi there,

    i try to settle some time accuracy in our office environment...

    Our main server is running SuSE 9.3 on AMD64. I installed the xntp package from SuSE (Vers. 4.2.0a-35).
    Hardware: DELL Power Edge 2850

    uanme -a:
    Linux office 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

    /etc/ntp.conf:
    --- snip ---
    driftfile /var/lib/ntp/drift/ntp.drift

    server 127.127.1.0
    fudge 127.127.1.0 stratum 13

    server 0.debian.pool.ntp.org iburst
    server 1.debian.pool.ntp.org iburst
    server 2.debian.pool.ntp.org iburst
    server 3.debian.pool.ntp.org iburst

    disable auth
    --- snap ---

    Short after starting, everythings looks ok:
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    *typhoon.aput.ne 192.12.19.20 2 u 227 256 377 170.905 -14.600 5.776
    +bitvalve.org 192.53.103.108 2 u 166 256 377 32.163 -15.190 4.488
    +8.15.10.42 132.163.4.103 2 u 170 256 377 105.118 -11.706 3.857
    -ns.oredin.net 193.190.230.66 2 u 179 256 277 141.835 36.960 17.438
    LOCAL(0) LOCAL(0) 13 l 49 64 377 0.000 0.000 0.001

    But after 3..5 hours all peers are rejected (ntpq> as) and LOCAL(0) is the sync source.

    I checked the firewall, disabled all restrict settings, disabled chroot and running as unprivileged user, a.s.o.

    Now i found that pps stability is always 512ppm and pll has a huge offset.

    ntpdc> kern:
    pll offset: 4294.95 s
    pll frequency: 22.694 ppm
    maximum error: 0.364061 s
    estimated error: 0.017754 s
    status: 0001 pll
    pll time constant: 4
    precision: 1e-06 s
    frequency tolerance: 512 ppm
    pps frequency: 0.000 ppm
    pps stability: 512.000 ppm
    pps jitter: 0.0002 s
    calibration interval: 4 s
    calibration cycles: 0
    jitter exceeded: 0
    stability exceeded: 0
    calibration errors: 0

    I set the hwclock -w and started fro scratch, but short after the offset was the same.
    I can't believe that the clock of this server is this terribly inaccurate... IMHO it's "professional" hardware. At least it was
    expensive

    Any help would be very much appreciated!
    Till


  2. Re: Stability problem on PowerEdge (SuSE 9.3)

    Till Wimmer wrote:
    > Hi there,
    >
    > i try to settle some time accuracy in our office environment...
    >
    > Our main server is running SuSE 9.3 on AMD64. I installed the xntp
    > package from SuSE (Vers. 4.2.0a-35).
    > Hardware: DELL Power Edge 2850
    >
    > uanme -a:
    > Linux office 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006
    > x86_64 x86_64 x86_64 GNU/Linux
    >
    > /etc/ntp.conf:
    > --- snip ---
    > driftfile /var/lib/ntp/drift/ntp.drift
    >
    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 13
    >
    > server 0.debian.pool.ntp.org iburst
    > server 1.debian.pool.ntp.org iburst
    > server 2.debian.pool.ntp.org iburst
    > server 3.debian.pool.ntp.org iburst
    >
    > disable auth
    > --- snap ---
    >
    > Short after starting, everythings looks ok:
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    >
    > *typhoon.aput.ne 192.12.19.20 2 u 227 256 377 170.905 -14.600
    > 5.776
    > +bitvalve.org 192.53.103.108 2 u 166 256 377 32.163 -15.190
    > 4.488
    > +8.15.10.42 132.163.4.103 2 u 170 256 377 105.118 -11.706
    > 3.857
    > -ns.oredin.net 193.190.230.66 2 u 179 256 277 141.835 36.960
    > 17.438
    > LOCAL(0) LOCAL(0) 13 l 49 64 377 0.000 0.000
    > 0.001
    >
    > But after 3..5 hours all peers are rejected (ntpq> as) and LOCAL(0) is
    > the sync source.
    >
    > I checked the firewall, disabled all restrict settings, disabled chroot
    > and running as unprivileged user, a.s.o.
    >
    > Now i found that pps stability is always 512ppm and pll has a huge offset.
    >
    > ntpdc> kern:
    > pll offset: 4294.95 s
    > pll frequency: 22.694 ppm
    > maximum error: 0.364061 s
    > estimated error: 0.017754 s
    > status: 0001 pll
    > pll time constant: 4
    > precision: 1e-06 s
    > frequency tolerance: 512 ppm
    > pps frequency: 0.000 ppm
    > pps stability: 512.000 ppm
    > pps jitter: 0.0002 s
    > calibration interval: 4 s
    > calibration cycles: 0
    > jitter exceeded: 0
    > stability exceeded: 0
    > calibration errors: 0
    >
    > I set the hwclock -w and started fro scratch, but short after the offset
    > was the same.
    > I can't believe that the clock of this server is this terribly
    > inaccurate... IMHO it's "professional" hardware. At least it was
    > expensive
    >
    > Any help would be very much appreciated!
    > Till
    >


    Three of your servers have round trip delays that are extreme by most
    standards. Try to find servers closer to you. I don't use pool servers
    myself but I believe that you can select regional servers by; e.g.
    us.pool.ntp.org for servers in the United states
    eu.pool.ntp.org for servers in Europe
    etc.

    Twenty milliseconds round trip delay is a good number. Make every
    effort to stay below thirty milliseconds.



  3. Re: Stability problem on PowerEdge (SuSE 9.3)

    Richard B. gilbert wrote:

    >
    > Three of your servers have round trip delays that are extreme by most
    > standards. Try to find servers closer to you. I don't use pool servers
    > myself but I believe that you can select regional servers by; e.g.
    > us.pool.ntp.org for servers in the United states
    > eu.pool.ntp.org for servers in Europe
    > etc.
    >
    > Twenty milliseconds round trip delay is a good number. Make every
    > effort to stay below thirty milliseconds.
    >

    Thanx for the prompt answer!

    OK, i understand: PPS aren't relevant because PPS isn't enabled.

    Now i put [..3].ch.pool.ntp.org in the ntp.conf.

    The delays decreased a lot!

    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    *bigben.solnet.c 195.66.241.3 2 u 34 64 7 29.746 3.248 3.301
    +elk.trapper.ch 10.0.0.2 2 u 30 64 7 24.517 1.666 6.871
    +soho.solnet.ch 131.188.3.221 2 u 35 64 7 13.905 0.834 3.194
    -entry.verboten. 130.149.17.21 2 u 29 64 7 14.606 4.572 2.314
    LOCAL(0) LOCAL(0) 13 l 31 64 7 0.000 0.000 0.001


    So let's see in a few hours...

    b.g.
    Till



  4. Re: Stability problem on PowerEdge (SuSE 9.3)

    but:

    ntpdc> sysi shows:

    --snap--
    root distance: 0.02536 s
    root dispersion: 0.06160 s
    reference ID: [62.65.148.250]
    reference time: c98b0322.2c93ea2d Sat, Feb 24 2007 19:32:02.174
    system flags: auth monitor ntp kernel stats
    jitter: 0.041702 s
    stability: 48.628 ppm


    stability is still not that good... and getting worse!

    On a different machine i started ntpd at almost the same time. The stability there was beyond 0.1 ppm short after...

    I'm still thinking there's something wrong with my hardware--- any ideas?

    Till

  5. Re: Stability problem on PowerEdge (SuSE 9.3)

    Till Wimmer wrote:
    > but:
    >
    > ntpdc> sysi shows:
    >
    > --snap--
    > root distance: 0.02536 s
    > root dispersion: 0.06160 s
    > reference ID: [62.65.148.250]
    > reference time: c98b0322.2c93ea2d Sat, Feb 24 2007 19:32:02.174
    > system flags: auth monitor ntp kernel stats
    > jitter: 0.041702 s
    > stability: 48.628 ppm
    >
    >
    > stability is still not that good... and getting worse!
    >
    > On a different machine i started ntpd at almost the same time. The
    > stability there was beyond 0.1 ppm short after...
    >
    > I'm still thinking there's something wrong with my hardware--- any ideas?

    There were/(are?) issues with some hardware ( nVidia chipsets, at least NV2)
    or/and apic stuff.
    Either boot the "safe settings" entry in the boot menu or
    add "noapic" and/or "noacpi" to your kernel options.

    fill in some options in the "options" item

    This may help.

    >
    > Till

    uwe


  6. Re: Stability problem on PowerEdge (SuSE 9.3)

    Hi Uwe,

    i already did put acpi=off s int the grub's kernel line. It didn't
    change anything.

    Now i think it's probably an network issue.
    A few hours after starting ntpd it always looks like this
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    bigben.solnet.c 195.66.241.3 2 u 849 1024 377 2033.34 992.089
    0.816
    elk.trapper.ch 10.0.0.2 2 u 928 1024 377 2186.13 964.833
    22.731
    soho.solnet.ch 131.188.3.222 2 u 927 1024 377 2017.19 993.271
    1.285
    entry.verboten. 17.72.133.55 2 u 859 1024 377 2015.20 992.412
    1.060
    *LOCAL(0) LOCAL(0) 13 l 8 64 377 0.000 0.000
    0.001

    Then i pinged elk.trapper.ch:PING elk.trapper.ch (62.65.148.250) 56(84)
    bytes of data.
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=1 ttl=56 time=2036 ms
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=2 ttl=56 time=1038 ms
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=3 ttl=56 time=40.1 ms
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=4 ttl=56 time=51.3 ms
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=5 ttl=56 time=55.9 ms
    64 bytes from elk.trapper.ch (62.65.148.250): icmp_seq=6 ttl=56 time=26.3 ms

    After that ping, the table looked different:
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    bigben.solnet.c 195.66.241.2 2 u 164 1024 377 2104.73 1022.29
    30.207
    elk.trapper.ch 10.0.0.2 2 u 245 1024 377 31.183 -9.198
    855.750

    My ping changed something in the ntp behaviour! Very strange thing...

    b.g.
    Till


    Uwe Klein wrote:
    >> I'm still thinking there's something wrong with my hardware--- any ideas?

    > There were/(are?) issues with some hardware ( nVidia chipsets, at least
    > NV2)
    > or/and apic stuff.
    > Either boot the "safe settings" entry in the boot menu or
    > add "noapic" and/or "noacpi" to your kernel options.
    >
    > fill in some options in the "options" item
    >
    > This may help.
    >
    >>
    >> Till

    > uwe
    >


  7. Re: Stability problem on PowerEdge (SuSE 9.3)


    >Now i think it's probably an network issue.
    >A few hours after starting ntpd it always looks like this
    > remote refid st t when poll reach delay offset
    >jitter
    >================================================== ============================
    > bigben.solnet.c 195.66.241.3 2 u 849 1024 377 2033.34 992.089
    > 0.816
    > elk.trapper.ch 10.0.0.2 2 u 928 1024 377 2186.13 964.833
    >22.731

    ....

    Are you on the end of a slow and busy link?

    That's a 2 second delay. The offset of 1 second makes me think
    that the system got started when the link was idle and now
    the round trip time is 2 seconds. ntp will assume that the
    delay is symmetric. You would see something like this if
    all (most) of the delay was in one direction.

    Note the reach data of 377 shows that no packets are getting lost.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  8. Re: Stability problem on PowerEdge (SuSE 9.3)

    Hal Murray wrote:
    >> Now i think it's probably an network issue.
    >> A few hours after starting ntpd it always looks like this
    >> remote refid st t when poll reach delay offset
    >> jitter
    >> ================================================== ============================
    >> bigben.solnet.c 195.66.241.3 2 u 849 1024 377 2033.34 992.089
    >> 0.816
    >> elk.trapper.ch 10.0.0.2 2 u 928 1024 377 2186.13 964.833
    >> 22.731

    > ...
    >
    > Are you on the end of a slow and busy link?
    >
    > That's a 2 second delay. The offset of 1 second makes me think
    > that the system got started when the link was idle and now
    > the round trip time is 2 seconds. ntp will assume that the
    > delay is symmetric. You would see something like this if
    > all (most) of the delay was in one direction.
    >
    > Note the reach data of 377 shows that no packets are getting lost.
    >

    We're on a fixed IP DSL line which always should be up. Otherwise i
    would not have been able to log into the server for the pinging...

    The pinging results make me believe that this issue is provoked by some
    latency policies of our provider.

    Till


  9. Re: Stability problem on PowerEdge (SuSE 9.3)

    now i found this in the logile:
    25 Feb 22:08:50 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    25 Feb 23:08:53 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 00:08:56 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 01:08:59 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 02:09:02 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 03:09:05 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 04:09:08 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    26 Feb 05:09:11 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error 0.000001 poll 10
    --- snap ---

    Could this be a hint to solve the problem?


    Till

  10. Re: Stability problem on PowerEdge (SuSE 9.3)

    Till Wimmer wrote:
    > now i found this in the logile:
    > 25 Feb 22:08:50 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 25 Feb 23:08:53 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 00:08:56 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 01:08:59 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 02:09:02 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 03:09:05 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 04:09:08 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > 26 Feb 05:09:11 ntpd[12147]: offset 0.000000 sec freq 8.321 ppm error
    > 0.000001 poll 10
    > --- snap ---
    >
    > Could this be a hint to solve the problem?
    >
    >
    > Till


    That looks very stable to me!


  11. Re: Stability problem on PowerEdge (SuSE 9.3)

    Richard B. gilbert wrote:

    >
    > That looks very stable to me!
    >

    It' sync'd to LOCALHOST(0)...

  12. Re: Stability problem on PowerEdge (SuSE 9.3)

    On 2007-02-24, Till Wimmer wrote:

    > Our main server is running SuSE 9.3 on AMD64. I installed the xntp
    > package from SuSE (Vers. 4.2.0a-35). Hardware: DELL Power Edge 2850
    >
    > uanme -a:
    > Linux office 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux


    > /etc/ntp.conf:


    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 13


    You should comment out the LocalCLK until you fix your stability
    problem. And then, you should only re-enable the LocalCLK if you
    understand why you need it.

    > server 0.debian.pool.ntp.org iburst
    > server 1.debian.pool.ntp.org iburst
    > server 2.debian.pool.ntp.org iburst
    > server 3.debian.pool.ntp.org iburst


    Some people will tell you that this is a poor choice of servers (e.g.
    due to excessive delay). That may be true but it's not germane to your
    problem.

    > disable auth


    Disabling auth is not usually a good idea because it can allow someone
    with ntpdc to tinker with your ntpd settings remotely. BUT ... this has
    nothing to do with your problem.

    > Short after starting, everythings looks ok:




    > But after 3..5 hours all peers are rejected (ntpq> as) and LOCAL(0) is
    > the sync source.


    We need to see 'ntpq -p' after your ntpd has been running for those 3-5
    hours. We also need to see any ntpd messages in your syslog for that
    same period.

    > Now i found that pps stability is always 512ppm and pll has a huge offset.


    You're not using PPS. Look at the PLL frequency, not the PPS stability.

    > ntpdc> kern:
    > pll offset: 4294.95 s
    > pll frequency: 22.694 ppm


    The offset is large because your system has been coasting on the
    Undisciplined Local Clock and ntpd has not had been able to determine
    the right PLL frequency.

    > I can't believe that the clock of this server is this terribly
    > inaccurate... IMHO it's "professional" hardware. At least it was
    > expensive


    Price and quality are not always synonymous.

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

  13. Re: Stability problem on PowerEdge (SuSE 9.3)

    hi steve,

    Steve Kostecke wrote:
    > On 2007-02-24, Till Wimmer wrote:
    >
    >> Our main server is running SuSE 9.3 on AMD64. I installed the xntp
    >> package from SuSE (Vers. 4.2.0a-35). Hardware: DELL Power Edge 2850
    >>
    >> uanme -a:
    >> Linux office 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

    >
    >> /etc/ntp.conf:

    >
    >> server 127.127.1.0
    >> fudge 127.127.1.0 stratum 13

    >
    > You should comment out the LocalCLK until you fix your stability
    > problem. And then, you should only re-enable the LocalCLK if you
    > understand why you need it.

    Well i confess, i'm new to ntp problematics... i thought we need this because all other servers in the LAN are sync'ed to this
    one. We need, at least, the same time on every server.

    >
    >> server 0.debian.pool.ntp.org iburst
    >> server 1.debian.pool.ntp.org iburst
    >> server 2.debian.pool.ntp.org iburst
    >> server 3.debian.pool.ntp.org iburst

    >
    > Some people will tell you that this is a poor choice of servers (e.g.
    > due to excessive delay). That may be true but it's not germane to your
    > problem.

    I changed them to ch.pools.... see follow ups
    >
    >> disable auth

    >
    > Disabling auth is not usually a good idea because it can allow someone
    > with ntpdc to tinker with your ntpd settings remotely. BUT ... this has
    > nothing to do with your problem.

    i disabled everything that could be restrective in some way.
    >
    >> Short after starting, everythings looks ok:

    >
    >
    >
    >> But after 3..5 hours all peers are rejected (ntpq> as) and LOCAL(0) is
    >> the sync source.

    >
    > We need to see 'ntpq -p' after your ntpd has been running for those 3-5
    > hours. We also need to see any ntpd messages in your syslog for that
    > same period.


    Tue Feb 27 16:29:09 CET 2007:
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    entry.verboten. 130.149.17.21 2 u 296 1024 377 2110.41 906.197 30.261
    ns1.nexellent.n 193.190.230.66 2 u 36 1024 377 2021.64 867.787 6.034
    bryan.solnet.ch 192.53.103.104 2 u 1005 1024 377 2015.45 878.894 2.276
    idaixds2.unizh. 130.60.128.7 3 u 1027 1024 376 2012.79 877.746 2.344
    *LOCAL(0) LOCAL(0) 10 l 7 64 377 0.000 0.000 0.001

    /var/log/ntp:
    26 Feb 22:01:28 ntpd[26518]: synchronized to 217.147.208.1, stratum 2
    26 Feb 22:25:17 ntpd[26518]: synchronized to 80.74.132.178, stratum 2
    26 Feb 22:52:34 ntpd[26518]: offset -0.004164 sec freq 10.024 ppm error 0.007587 poll 8
    26 Feb 23:18:30 ntpd[26518]: synchronized to 217.147.208.1, stratum 2
    26 Feb 23:52:37 ntpd[26518]: offset -0.004624 sec freq 9.597 ppm error 0.000965 poll 9
    27 Feb 00:06:12 ntpd[26518]: synchronized to 80.74.132.178, stratum 2
    27 Feb 00:10:00 ntpd[26518]: synchronized to 212.101.4.253, stratum 3
    27 Feb 00:15:52 ntpd[26518]: synchronized to LOCAL(0), stratum 10
    27 Feb 00:52:40 ntpd[26518]: offset 0.000000 sec freq 9.597 ppm error 0.000001 poll 10
    27 Feb 01:52:43 ntpd[26518]: offset 0.000000 sec freq 9.597 ppm error 0.000001 poll 10
    27 Feb 02:52:46 ntpd[26518]: offset 0.000000 sec freq 9.597 ppm error 0.000001 poll 10
    -- snap --
    last line stays the same for the remaining of the day


    >
    >> Now i found that pps stability is always 512ppm and pll has a huge offset.

    >
    > You're not using PPS. Look at the PLL frequency, not the PPS stability.

    i got this... see follow ups
    >
    >

    so the question remains...

    bg
    till

  14. Re: Stability problem on PowerEdge (SuSE 9.3)

    On 2007-02-27, Till Wimmer wrote:

    > Steve Kostecke wrote:
    >
    >> You should comment out the LocalCLK until you fix your stability
    >> problem. And then, you should only re-enable the LocalCLK if you
    >> understand why you need it.

    >
    > Well i confess, i'm new to ntp problematics... i thought we need this
    > because all other servers in the LAN are sync'ed to this one. We need,
    > at least, the same time on every server.


    Using the LocalCLK allows your NTP to claim to be synced when your real
    time sources are unavailable. This can be useful, but is not required,
    when you are serving to to others.

    The problem right now is that ntpd is seeing the LocalCLK as better.
    This is interfering with solving your problem.

    >> Some people will tell you that this is a poor choice of servers (e.g.
    >> due to excessive delay). That may be true but it's not germane to
    >> your problem.

    >
    > I changed them to ch.pools... see follow ups


    I know you changed them. And, as we saw, doing so had no effect on your
    problem.

    >> Disabling auth is not usually a good idea because it can allow
    >> someone with ntpdc to tinker with your ntpd settings remotely. BUT
    >> ... this has nothing to do with your problem.

    >
    > i disabled everything that could be restrective in some way.


    Authentication has nothing to do with time service unless you have
    explictly configured your ntpd to require authentication for certain
    associations. But, you haven't done so.

    >remote refid st t when poll reach delay offset jitter
    >================================================== ============================
    >entry.verboten. 130... 2 u 296 1024 377 2110.41 906.197 30.261
    >ns1.nexellent.n 193... 2 u 36 1024 377 2021.64 867.787 6.034
    >bryan.solnet.ch 192... 2 u 1005 1024 377 2015.45 878.894 2.276
    >idaixds2.unizh. 130... 3 u 1027 1024 376 2012.79 877.746 2.344
    >*LOCAL(0) LOCAL(0) 10 l 7 64 377 0.000 0.000 0.001


    The jitter isn't bad.

    > /var/log/ntp:


    It looks like ntpd did not have to step your clock. That's a good sign.

    > so the question remains...


    I'd try running this ntpd without the LocalCLK to see ntpd is able to
    sync with your remote time servers.

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

  15. Re: Stability problem on PowerEdge (SuSE 9.3)

    Steve Kostecke wrote:

    > Authentication has nothing to do with time service unless you have
    > explictly configured your ntpd to require authentication for certain
    > associations. But, you haven't done so.

    .... but who knows if SuSE didn't touch the default settings

    > I'd try running this ntpd without the LocalCLK to see ntpd is able to
    > sync with your remote time servers.

    OK, i'll try this now... Thanks for the hints and sorry for bothering you!

    bg
    till

+ Reply to Thread