Re: ntpd server on Linux/Debian with SPARC Sun Blade100 - NTP

This is a discussion on Re: ntpd server on Linux/Debian with SPARC Sun Blade100 - NTP ; Hello all, I'm back to my ntp server setup problem... I have found a link to a problem with the Sun Blade 100 and it's clock: http://people.spacelabs.nl/~admar/usb100faq/76.html Of course, this is talking about Solaris, and I use Linux... But maybe ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Re: ntpd server on Linux/Debian with SPARC Sun Blade100

  1. Re: ntpd server on Linux/Debian with SPARC Sun Blade100

    Hello all,

    I'm back to my ntp server setup problem...

    I have found a link to a problem with the Sun Blade 100 and it's clock:

    http://people.spacelabs.nl/~admar/usb100faq/76.html

    Of course, this is talking about Solaris, and I use Linux... But maybe
    the cause of the problem is the same: a problem with the Sun Blade 100
    clock. In the log of ntp, I see many "time reset" (about every 15
    minutes), like:

    Oct 19 06:40:19 puck ntpd[2779]: time reset +1.018025 s
    Oct 19 06:56:20 puck ntpd[2779]: time reset +0.873713 s
    Oct 19 07:12:29 puck ntpd[2779]: time reset +0.609030 s
    Oct 19 07:34:00 puck ntpd[2779]: time reset +1.072741 s
    Oct 19 07:50:06 puck ntpd[2779]: time reset +0.777131 s
    Oct 19 08:09:30 puck ntpd[2779]: time reset +0.877752 s
    Oct 19 08:27:47 puck ntpd[2779]: time reset +1.226723 s
    Oct 19 08:43:52 puck ntpd[2779]: time reset +0.692576 s
    Oct 19 08:58:50 puck ntpd[2779]: time reset +0.563637 s
    Oct 19 09:13:57 puck ntpd[2779]: time reset +0.733451 s
    Oct 19 09:31:08 puck ntpd[2779]: time reset +0.865823 s
    Oct 19 10:07:50 puck ntpd[17152]: time reset +1.950348 s
    Oct 19 10:26:08 puck ntpd[17152]: time reset +0.755067 s
    Oct 19 10:41:42 puck ntpd[17152]: time reset +0.827267 s
    Oct 19 10:52:18 puck ntpd[27745]: time reset +0.713711 s
    Oct 19 11:06:49 puck ntpd[27745]: time reset +0.704562 s
    Oct 19 11:22:07 puck ntpd[27745]: time reset +0.733117 s
    Oct 19 11:42:08 puck ntpd[27745]: time reset +0.992933 s

    The ntpd server is staying in stratum 16.

    Is there something I can do to have this Linux Sun Blade 100 running as
    a ntp server correctly ? I already have try to compile and install the
    last ntp stable version (4.2.2p4), and the problem stay the same.
    Current kernel is stock 2.6.17.11 with linux vserver patch.

    Thanks in advance for any help, and have a nice day.

    Olivier

    PS: Just for reference, as my previous email is a little bit old...:
    On Fri, Sep 01, 2006 at 05:26:16PM +0200, wrote:
    > I'm trying to setup a server on a Linux/Debian system. The hardware is a
    > Sun Blade 100. It's running the stable distribution of Debian, but with
    > a 2.6.16 kernel (and some few libs from testing).
    >
    > The goal is to offer it in the pool.ntp.org as ntpd server.
    >
    > So, I have choose 5 Swiss server to synchronize with (stratum 2). Here
    > is the ntpq -p output:
    >
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > *audon.favey.ch 213.144.132.141 2 u 8 64 377 10.709 666.749 117.620
    > +cctld.tix.ch 130.149.17.21 2 u 8 64 377 5.283 662.468 111.763
    > -ns1.toponline.c 129.132.2.21 3 u 11 64 377 12.718 739.712 171.543
    > -tick.meteonews. 131.188.3.222 2 u 13 64 377 9.637 539.017 167.573
    > +sake.ifi.unizh. 131.188.3.220 2 u 16 64 377 5.463 659.900 111.388
    >
    > The ntpdc -c peers give me:
    >
    > remote local st poll reach delay offset disp
    > ================================================== =====================
    > =sake.ifi.unizh. 153.109.180.3 2 64 377 0.00546 0.659900 0.05933
    > =ns1.toponline.c 153.109.180.3 3 64 377 0.01271 0.739712 0.05917
    > *audon.favey.ch 153.109.180.3 2 64 377 0.01070 0.666749 0.05872
    > =tick.meteonews. 153.109.180.3 2 64 377 0.00926 0.852017 0.03731
    > =cctld.tix.ch 153.109.180.3 2 64 377 0.00528 0.662468 0.05414
    >
    > What is strange is the the offset seems to me a little bit too high. I
    > have compared this to my own Debian/x86 system. In this case, the offset
    > is more close to 0.001 (almost 100 times smaller).
    >
    > Has someone an idea why this is so bad ? Is the Debian/SPARC64 a problem ?
    > Is the Blade 100 hardware the problem ? I don't really know where to
    > search. I already have upgraded the kernel from a 2.4 to a 2.6.
    >
    > ntp sersion is ntp-server 1:4.2.0a+stable-2sarge1 from Debian stable.


    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFN0+Cdj3R/MU9khgRAmv5AJ94mcQBEB4U6U4DEKgUnA0HyRcjYwCgqe/F
    O8263Z1eo7arLCqHuccHbUg=
    =dRdy
    -----END PGP SIGNATURE-----


  2. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    Olivier Bornet wrote:
    > Hello all,
    >
    > I'm back to my ntp server setup problem...
    >
    > I have found a link to a problem with the Sun Blade 100 and it's clock:
    >
    > http://people.spacelabs.nl/~admar/usb100faq/76.html
    >
    > Of course, this is talking about Solaris, and I use Linux... But maybe
    > the cause of the problem is the same: a problem with the Sun Blade 100
    > clock. In the log of ntp, I see many "time reset" (about every 15
    > minutes), like:

    i had a similar problem the other way round ( clock gaining) while your
    clock seems to be loosing.
    when you do not use ntpd does the clock start to lag rather fast?

    While searching for my problem i seem to remenber some issue with loosing
    timer interrupts ( i.e. This may not be ntpd related )

    G!
    uwe


  3. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    Olivier Bornet wrote:

    > Hello all,
    >
    > I'm back to my ntp server setup problem...
    >
    > I have found a link to a problem with the Sun Blade 100 and it's clock:
    >
    > http://people.spacelabs.nl/~admar/usb100faq/76.html
    >
    > Of course, this is talking about Solaris, and I use Linux... But maybe
    > the cause of the problem is the same: a problem with the Sun Blade 100
    > clock. In the log of ntp, I see many "time reset" (about every 15
    > minutes), like:
    >
    > Oct 19 06:40:19 puck ntpd[2779]: time reset +1.018025 s
    > Oct 19 06:56:20 puck ntpd[2779]: time reset +0.873713 s


    There is a well known problem with some flavors of Linux. There is a
    kernel parameter, HZ, which, if set to "250" or "1000" can cause the
    loss of clock interrupts. It should be set to 100 for best results.

    Another solution would be to download Solaris 10 (free) from Sun and
    install it.

  4. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    On 2006-10-19, Olivier Bornet wrote:

    > I have found a link to a problem with the Sun Blade 100 and it's clock:
    >
    > http://people.spacelabs.nl/~admar/usb100faq/76.html
    >
    > Of course, this is talking about Solaris, and I use Linux... But maybe
    > the cause of the problem is the same: a problem with the Sun Blade 100
    > clock. In the log of ntp, I see many "time reset" (about every 15
    > minutes), like:


    Adjusting your tick may help. See the "Mac Mini
    (and other machines having poor TICK settings)" section of
    http://ntp.isc.org/bin/view/Support/KnownHardwareIssues

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

  5. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 12:56:55PM +0000, Steve Kostecke wrote:
    > Adjusting your tick may help. See the "Mac Mini
    > (and other machines having poor TICK settings)" section of
    > http://ntp.isc.org/bin/view/Support/KnownHardwareIssues


    Thanks for the link. If setting the HZ don't resolve my problem, I will
    try to adjust the drift.

    Have a nice day.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFN4agdj3R/MU9khgRAoYNAKC1qiQKGuj+jU6bsbvwF7mk+ahJxQCgiTRl
    QNnHswp+bE9vXL1EzbnghS8=
    =pJEI
    -----END PGP SIGNATURE-----


  6. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 08:55:17AM -0400, Richard B. Gilbert wrote:
    > There is a well known problem with some flavors of Linux. There is a
    > kernel parameter, HZ, which, if set to "250" or "1000" can cause the
    > loss of clock interrupts. It should be set to 100 for best results.


    Right ! It was originally at 250, and I already have test it at 1000
    (because I was thinking that if it is higher, it will be more precise.
    Seems I was wrong).

    Compilation of a new kernel with 100 is now in progress... I will keep
    you informed on the status with ntpd.

    > Another solution would be to download Solaris 10 (free) from Sun and
    > install it.


    Hummm... I prefer to stay with Linux... Even if Solaris 10 is free. But
    thanks for the proposition.

    Thanks for your help.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFN4Y+dj3R/MU9khgRAkRaAJ9uCzOXPJldxlg09n4ovJKvOWuXOACeL5uR
    q7TZgdDPd5214L/LG1az/dk=
    =hH+1
    -----END PGP SIGNATURE-----


  7. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 01:23:36PM +0200, Uwe Klein wrote:
    > i had a similar problem the other way round ( clock gaining) while your
    > clock seems to be loosing.
    > when you do not use ntpd does the clock start to lag rather fast?


    I have manually check without ntpd, and after 2 hours, the system has
    loose about 6 seconds. So, about 2 seconds per hour seems to be too much
    for ntpd.

    > While searching for my problem i seem to remenber some issue with loosing
    > timer interrupts ( i.e. This may not be ntpd related )


    Right. I hope that the solution suggested by the other emails to set HZ
    to 100 instead of 250 or 1000, or adjust the drift will correct the
    problem. If not, I will look in the interrupts direction.

    Thanks for your answer, and have a nice day.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFN4gydj3R/MU9khgRAtJ0AJ9iwP8ew37FU9hfL6amOYUE7JKu4gCbBJCs
    jyUWoUFZTHjQYPSzNYl28MA=
    =Tt+S
    -----END PGP SIGNATURE-----


  8. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    Olivier Bornet wrote:

    > Hello,
    >
    > On Thu, Oct 19, 2006 at 01:23:36PM +0200, Uwe Klein wrote:
    >
    >>i had a similar problem the other way round ( clock gaining) while your
    >>clock seems to be loosing.
    >>when you do not use ntpd does the clock start to lag rather fast?

    >
    >
    > I have manually check without ntpd, and after 2 hours, the system has
    > loose about 6 seconds. So, about 2 seconds per hour seems to be too much
    > for ntpd.
    >
    >
    >>While searching for my problem i seem to remenber some issue with loosing
    >>timer interrupts ( i.e. This may not be ntpd related )

    >
    >
    > Right. I hope that the solution suggested by the other emails to set HZ
    > to 100 instead of 250 or 1000, or adjust the drift will correct the
    > problem. If not, I will look in the interrupts direction.



    If lost interrupts are the problem, you probably should not try to fix
    it by trying to tinker with the "drift". The reason is that the lost
    interrupts are the result of device drivers, probably disk drivers,
    disabling or masking interrupts for too long a time. If this is the
    case, the problem should disappear when the machine is not busy. (If
    you tinker and the problem disappears when the machine is not busy, your
    clock will be off again when the machine is not busy.)

  9. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100


  10. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    In article <20061019141410.GH12952@puck.ch>,
    Olivier.Bornet@puck.ch (Olivier Bornet) wrote:
    > On Thu, Oct 19, 2006 at 01:23:36PM +0200, Uwe Klein wrote:
    > > i had a similar problem the other way round ( clock gaining) while your
    > > clock seems to be loosing.


    Gaining can happen for the other two reasons mentioned below, but it
    excludes lost interrupts.

    > I have manually check without ntpd, and after 2 hours, the system has
    > loose about 6 seconds. So, about 2 seconds per hour seems to be too much
    > for ntpd.


    That's correct. The maximum theoretically correctable error is one
    second in every 2,000, however that means the control loop is non-linear
    in one direction, so you really need an error that's maybe 10% less.

    > Right. I hope that the solution suggested by the other emails to set HZ
    > to 100 instead of 250 or 1000, or adjust the drift will correct the
    > problem. If not, I will look in the interrupts direction.


    Adjusting the drift file only speeds up the convergence process, it cannot
    apply total corrections of more than the same 500ppm mentioned above.
    Moreover, a system which needs such a correction is broken to the point
    where it needs fixing first. If you are loosing clock interrupts, you
    will prevent the control loop going into its accurate mode and you will
    have semi random steps in the time. If the oscillator is out by this
    amount, the crystal is either dying or has died, and the clock is running
    as an LC oscillator. If the software is scaling by the wrong factor, it
    needs to be fixed to scale by the correct one.

    Note there is a parameter, which allows you to modify the assumed length
    of a tick in microsecond step, which can be used to provide coarse correction,
    but, as noted above, the system is probably broken if you need to use it
    on modern systems (some older systems didn't have a full 500ppm correction
    range, and I've observed crystals that seem to have been out by 100 to
    200 ppm).

    One other thing that will give continued steps in the same direction is
    having something else trying to set the software clock. This will happen
    with "out of the box" SunOS and SCO OpenServer systems.

  11. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    David Woolley wrote:
    > In article <20061019141410.GH12952@puck.ch>,
    > Olivier.Bornet@puck.ch (Olivier Bornet) wrote:
    >
    >>On Thu, Oct 19, 2006 at 01:23:36PM +0200, Uwe Klein wrote:
    >>
    >>>i had a similar problem the other way round ( clock gaining) while your
    >>>clock seems to be loosing.

    >
    >
    > Gaining can happen for the other two reasons mentioned below, but it
    > excludes lost interrupts.


    Just to have it on record:
    Clock gaining fast on Linux is in my case connected to nVidia nForce 1/2
    based Motherboards of certain revisions.
    If the Timer interrupt is routed via APIC and ( in some cases) Spread Spectrum
    is activated in the BIOS this interrupt will be handled twice on occasion.

    this appears in the logfile as:
    13 Aug 15:17:46 ntpd[11378]: synchronized to LOCAL(0), stratum 10
    13 Aug 15:18:50 ntpd[11378]: kernel time sync enabled 0001
    13 Aug 16:04:57 ntpd[11378]: synchronized to 123.33.160.1, stratum 2
    13 Aug 16:21:59 ntpd[11378]: time reset -2.118908 s
    13 Aug 16:26:15 ntpd[11378]: synchronized to LOCAL(0), stratum 10
    13 Aug 16:56:25 ntpd[11378]: synchronized to 123.33.160.1, stratum 2
    13 Aug 17:13:26 ntpd[11378]: time reset -1.731393 s
    13 Aug 17:17:45 ntpd[11378]: synchronized to LOCAL(0), stratum 10
    13 Aug 17:30:45 ntpd[11378]: synchronized to 123.33.160.1, stratum 2
    13 Aug 17:47:50 ntpd[11378]: time reset -0.898465 s
    13 Aug 17:52:09 ntpd[11378]: synchronized to LOCAL(0), stratum 10



    uwe

  12. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 04:06:24PM +0000, Harlan Stenn wrote:
    > Have you seen http://ntp.isc.org/Support/TroubleshootingNTP ?


    Not really before. But now yes.
    Maybe my problem is the one described here:

    http://ntp.isc.org/bin/view/Support/...ection_9.2.4.3.

    called "Lost ticks causing clock instability". I have quickly read the
    kernel issue from the referenced link. Interesting. I will look more in
    detail if the drift adjustement I'm folowind now (like described in
    "9.1.6. Mac Mini (and other machines having poor TICK settings)" in the
    known hardware issue.

    Thanks for the link, and have a nice day.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFOJmPdj3R/MU9khgRAriVAKCOhFvDP5zLcea5l7XHNhf2t3JLEgCg6zcL
    fgVmvwSapXvQW4r16I51fVQ=
    =POHg
    -----END PGP SIGNATURE-----


  13. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 04:05:50PM +0200, Olivier Bornet wrote:
    > On Thu, Oct 19, 2006 at 08:55:17AM -0400, Richard B. Gilbert wrote:
    > > There is a well known problem with some flavors of Linux. There is a
    > > kernel parameter, HZ, which, if set to "250" or "1000" can cause the
    > > loss of clock interrupts. It should be set to 100 for best results.

    >
    > Right ! It was originally at 250, and I already have test it at 1000
    > (because I was thinking that if it is higher, it will be more precise.
    > Seems I was wrong).
    >
    > Compilation of a new kernel with 100 is now in progress... I will keep
    > you informed on the status with ntpd.


    I have booted and try the new kernel with 100 Hz. Problem stay the same:

    Oct 20 09:03:31 puck ntpd[3695]: time reset +0.414719 s
    Oct 20 09:16:27 puck ntpd[3695]: time reset +1.025004 s
    Oct 20 09:31:28 puck ntpd[3695]: time reset +0.619681 s
    Oct 20 09:48:36 puck ntpd[3695]: time reset +1.220567 s
    Oct 20 10:06:53 puck ntpd[3695]: time reset +1.608695 s
    Oct 20 10:26:14 puck ntpd[3695]: time reset +0.988006 s
    Oct 20 10:43:18 puck ntpd[3695]: time reset +1.285261 s
    Oct 20 11:04:50 puck ntpd[3695]: time reset +1.443082 s

    So, I will try to adjust my ticks, as suggested on the mailing list, and
    as described in:

    http://ntp.isc.org/bin/view/Support/...#Section_9.1.6.

    Stay tuned for the result...

    Have a nice day, and thanks everybody for the help.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFOJdwdj3R/MU9khgRAuEzAJ9ErTR8aj7aZMLNNFt1VFJsi1CrgwCeP/zB
    EtFPraUFl5S1DmV1s6yU0kM=
    =SciY
    -----END PGP SIGNATURE-----


  14. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Thu, Oct 19, 2006 at 11:07:56AM -0400, Richard B. Gilbert wrote:
    > If lost interrupts are the problem, you probably should not try to fix
    > it by trying to tinker with the "drift". The reason is that the lost
    > interrupts are the result of device drivers, probably disk drivers,
    > disabling or masking interrupts for too long a time. If this is the
    > case, the problem should disappear when the machine is not busy. (If
    > you tinker and the problem disappears when the machine is not busy, your
    > clock will be off again when the machine is not busy.)


    I don't think this is the case, as the machine is not really busy in
    general. Mainly, it "just" does web and mail server, and no big disk
    usage is done. And the problem seems constant. I don't really have see
    the ntpd server working correctly since I have started it about 2 months
    ago.

    Thanks for your help, and have a nice day.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFOJr9dj3R/MU9khgRAhQ7AJ4z80X9g0oLWo54vZc7uDCXcG71UgCg0RWP
    MM15EhjKKOr57Z7CMeq5Kuw=
    =7WOj
    -----END PGP SIGNATURE-----


  15. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    Hi there


    Olivier Bornet wrote:

    > Thanks for the link. If setting the HZ don't resolve my problem, I will
    > try to adjust the drift.


    AFAIK NTP can't handle asymmetrical link speeds. So if you have a busy
    ADSL link or a SDSL link with an asymmetrical load, NTPD gets the delay
    over the line wrong.

    I solved the problem with the '-x' option;

    Ordinarily, if the time is to be adjusted more than 128 ms, it is
    stepped, not gradually slewed. This option forces the time to be slewed
    in all cases.
    Note: Since the slew rate is limited to 0.5 ms/s, each second of
    adjustment requires an amortization interval of 2000 s. Thus an
    adjustment of many seconds can take hours or days to amortize.

    At boot the clock is synced with ntpdate, so the above doesn't cause any
    problems.


    Regards,
    Rob
    --
    There is only one good; knowledge, and one evil; ignorance (Socrates).
    Virtue is more to be feared than vice, because its excesses are not
    subject to the regulation of conscience (Adam Smith).

  16. Re: ntpd server on Linux/Debian with SPARC Sun Blade 100

    In article <4539f3de$0$324$e4fe514c@news.xs4all.nl>,
    Rob van der Putten wrote:
    > Olivier Bornet wrote:


    > > Thanks for the link. If setting the HZ don't resolve my problem, I will
    > > try to adjust the drift.


    > AFAIK NTP can't handle asymmetrical link speeds. So if you have a busy


    NTP cannot handle asymmetrical link delays, asymmetric speeds don't
    necessarily produce these because they tend to be used in contexts where
    the downlink traffic is much higher than the uplink traffic. In fact they
    are likely to produce errors in the opposite direction to what you might
    expected if you judged by link speed alone. Also, it is variability
    in the delay difference, not the mean value, that matters. (Actually,
    I'm not sure how any protocol could fully account for assymmetric delays.)

    In any case, this issue doesn't seem to be relevant in this case, as I
    believe he had unidirectional stepping, and if you have unidirectional
    stepping, it normally means that you would have to slew faster
    than 500ppm to catch up.

    > I solved the problem with the '-x' option;


    The option that is intended to deal with this case is the huff and puff
    tinker option. I believe, that in recent versions, -x sets the step
    limit high, but not infinite, and that high step limits cause the
    kernel PLL to be disabled.

    Given that almost all consumer links and probably many service provide
    links are assymmetrically loaded, I don't think it a good idea to
    advise -x in all such cases. A lot of people are continually trying
    to advise people against using it when they think they have a problem
    with databases.

    > At boot the clock is synced with ntpdate, so the above doesn't cause any
    > problems.


    ntpdate is deprecated. More interestingly, it seems that certain optimisations
    to achieve fast initial convergence only work if the initial time is outside
    the step limit!

  17. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello,

    On Sat, Oct 21, 2006 at 12:18:06PM +0200, Rob van der Putten wrote:
    > AFAIK NTP can't handle asymmetrical link speeds. So if you have a busy
    > ADSL link or a SDSL link with an asymmetrical load, NTPD gets the delay
    > over the line wrong.


    This is not a problem for me, as the server I'm trying to configure is
    not a a ADSL link. It's on a very good symetric connection.

    Have a nice day.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFOqUVdj3R/MU9khgRAh/NAKDLBPRoVNKISnU6LJ5r38n0SS1HgACfRcl9
    EvaX+52xB6gjx0HqWfORb4Q=
    =6v0G
    -----END PGP SIGNATURE-----


  18. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Hello all,

    On Fri, Oct 20, 2006 at 11:31:28AM +0200, Olivier Bornet wrote:
    > So, I will try to adjust my ticks, as suggested on the mailing list, and
    > as described in:
    >
    > http://ntp.isc.org/bin/view/Support/...#Section_9.1.6.
    >
    > Stay tuned for the result...


    So, the result...

    It's seems to be ok now.
    No more problem since this morning. Thanks for the link and all the
    help.

    Have a nice Sunday all.

    Olivier
    --
    Olivier Bornet
    Olivier.Bornet@puck.ch
    Swiss Ice Hockey Results : http://puck.ch/
    Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFFOqW+dj3R/MU9khgRAm+kAJ9e9HXaEc44+n7l1e4epmcOXYL18wCcDGXz
    5GMOUeOmfM99C2W/7a9teAY=
    =KhCc
    -----END PGP SIGNATURE-----


  19. Re: ntpd server on Linux/Debian with SPARC SunBlade 100

    Rob van der Putten wrote:
    > Hi there
    >
    >
    > Olivier Bornet wrote:
    >
    >> Thanks for the link. If setting the HZ don't resolve my problem, I will
    >> try to adjust the drift.

    >
    > AFAIK NTP can't handle asymmetrical link speeds. So if you have a busy
    > ADSL link or a SDSL link with an asymmetrical load, NTPD gets the delay
    > over the line wrong.


    Actually it can. IIRC it's one of the fudge parameters. The hard part is
    figuring out the adjustment to put in.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread