Re: Getting good NTP tracking - NTP

This is a discussion on Re: Getting good NTP tracking - NTP ; David Woolley wrote: > In article , > Richard B. Gilbert wrote: > > >>Look at your /etc/ntp.conf. In that file, look at the server >>statements. Do they include the keyword MINPOLL? Or MAXPOLL? > > > He included it ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: Getting good NTP tracking

  1. Re: Getting good NTP tracking

    David Woolley wrote:
    > In article ,
    > Richard B. Gilbert wrote:
    >
    >
    >>Look at your /etc/ntp.conf. In that file, look at the server
    >>statements. Do they include the keyword MINPOLL? Or MAXPOLL?

    >
    >
    > He included it in his original posting and it has been (over) quoted
    > several times since. He had no minpoll or maxpoll. It's really not
    > uncommon for the poll interval to stick at the maximum once the system
    > has stabilised.


    Sorry, I missed that, or thought he missed it. He didn't cut and paste
    it. His complaint seems to be that he's getting large offsets and that
    suggests to me that the system has NOT stabilized.

    Requoting the the numbers we're talking about:
    peers.20060620
    ident cnt mean rms max delay dist disp
    ================================================== ========================
    132 -4.089 90.922 986.193 4.340 939.038 30.380

    The University server seems to have been polled only 132 times in 24
    hours while the maximum offset is 986.193 milliseconds. I've used a few
    servers that looked that bad and the polling interval did not get very
    large. The picture suggests a network problem of some sort which I find
    a little surprising since the network he describes would seem to be a
    LAN or a small WAN (note the small value of delay).

    My NTP experience has been almost entirely with 10-base-T and 100-base-T
    switched full duplex technology. If he has 10-base-5 (thick coaxial
    cable) or 10-base-2 (thinwire) or even twisted pair with hubs instead of
    switches he could be getting enough phase noise from his network to
    force a long poll interval.

  2. Re: Getting good NTP tracking

    Richard B. Gilbert wrote:
    > David Woolley wrote:
    >> In article ,
    >> Richard B. Gilbert wrote:
    >>
    >>
    >>> Look at your /etc/ntp.conf. In that file, look at the server
    >>> statements. Do they include the keyword MINPOLL? Or MAXPOLL?

    >>
    >>
    >> He included it in his original posting and it has been (over) quoted
    >> several times since. He had no minpoll or maxpoll. It's really not
    >> uncommon for the poll interval to stick at the maximum once the system
    >> has stabilised.

    >
    > Sorry, I missed that, or thought he missed it. He didn't cut and paste
    > it. His complaint seems to be that he's getting large offsets and that
    > suggests to me that the system has NOT stabilized.
    >
    > Requoting the the numbers we're talking about:
    > peers.20060620
    > ident cnt mean rms max delay dist disp
    > ================================================== ========================
    > 132 -4.089 90.922 986.193 4.340 939.038 30.380
    >
    > The University server seems to have been polled only 132 times in 24
    > hours while the maximum offset is 986.193 milliseconds. I've used a few
    > servers that looked that bad and the polling interval did not get very
    > large. The picture suggests a network problem of some sort which I find
    > a little surprising since the network he describes would seem to be a
    > LAN or a small WAN (note the small value of delay).
    >
    > My NTP experience has been almost entirely with 10-base-T and 100-base-T
    > switched full duplex technology. If he has 10-base-5 (thick coaxial
    > cable) or 10-base-2 (thinwire) or even twisted pair with hubs instead of
    > switches he could be getting enough phase noise from his network to
    > force a long poll interval.


    This is actually on GigE, at least in my building - I'd assume the
    campus backbones are probably all GigE by now, certainly 100-base-T.
    The departmental NTP server should be in the same building with me, at
    least.

    I could certainly simply have one machine use an undisciplined local
    clock and point the other at it as the sole timing source, but when I
    tried that earlier, I didn't have any better luck in maintaining good
    tracking.

    I haven't yet collected enough data to tell if disabling SELinux and
    adding more servers will help - hopefully those will do the trick.


  3. Re: Getting good NTP tracking

    I've lost track of who's said what, but at some point the original
    poster mentioned that the offset gets worse during the day. To that I
    ask a question: Are the server(s) more utilized during the day? If
    so, would the gurus consider lost interrupts a possibility? Looks
    like CENTos uses the 2.6.x kernels which some have mentioned had
    trouble at least at some point in past.

    I mainly mention this because this has come up as a possibility
    several times over the previous months, and I was wondering if there
    is a way to diagnose this problem, either with NTP tools, or using
    OS tools.

    --
    Charles Allen


  4. Re: Getting good NTP tracking

    Charles Allen wrote:

    > I've lost track of who's said what, but at some point the original
    > poster mentioned that the offset gets worse during the day. To that I
    > ask a question: Are the server(s) more utilized during the day? If
    > so, would the gurus consider lost interrupts a possibility? Looks
    > like CENTos uses the 2.6.x kernels which some have mentioned had
    > trouble at least at some point in past.
    >
    > I mainly mention this because this has come up as a possibility
    > several times over the previous months, and I was wondering if there
    > is a way to diagnose this problem, either with NTP tools, or using
    > OS tools.
    >


    Lost interrupts result in the local clock being slow with respect to the
    server. The server will fall behind, step in the positive direction,
    fall behind again, step, etc. This seems to be a problem mostly with
    Linux systems that update the clock at frequencies greater than 100 Hz.
    Some systems can set the update frequency to 250 or 1000 Hz and those
    that do so have been known to exhibit this problem.

  5. Re: Getting good NTP tracking

    Richard B. Gilbert wrote:
    > Charles Allen wrote:
    >
    >> I've lost track of who's said what, but at some point the original
    >> poster mentioned that the offset gets worse during the day. To that I
    >> ask a question: Are the server(s) more utilized during the day? If
    >> so, would the gurus consider lost interrupts a possibility? Looks
    >> like CENTos uses the 2.6.x kernels which some have mentioned had
    >> trouble at least at some point in past.
    >>
    >> I mainly mention this because this has come up as a possibility
    >> several times over the previous months, and I was wondering if there
    >> is a way to diagnose this problem, either with NTP tools, or using
    >> OS tools.
    >>

    >
    > Lost interrupts result in the local clock being slow with respect to the
    > server. The server will fall behind, step in the positive direction,
    > fall behind again, step, etc. This seems to be a problem mostly with
    > Linux systems that update the clock at frequencies greater than 100 Hz.
    > Some systems can set the update frequency to 250 or 1000 Hz and those
    > that do so have been known to exhibit this problem.


    Where would I check on the clock update frequency?

    -----


    Peer stats from yesterday:

    peers.20060627
    ident cnt mean rms max delay dist disp
    ================================================== ========================
    A.A.A.A 133 0.604 2.726 11.346 99.133 69.698 11.311
    B.B.B.B 134 1.486 14.164 137.654 67.729 250.569 11.178
    C.C.C.C 123 32.648 34.108 176.643 119.703 264.385 19.212
    D.D.D.D 131 -2.643 67.035 731.930 0.486 22.607 11.261
    E.E.E.E 132 -0.432 1.872 17.620 3.671 37.519 11.287
    F.F.F.F 140 -2.113 1.226 4.530 0.998 938.963 39.071

    I'm not sure overall this is any better - however, the tracking with the
    peer F.F.F.F seems good - if it maintains track like this, I'll be
    satisfied.



  6. Re: Getting good NTP tracking

    Eino-Ville Talvala wrote:

    > Richard B. Gilbert wrote:
    >
    >> Charles Allen wrote:
    >>
    >>> I've lost track of who's said what, but at some point the original
    >>> poster mentioned that the offset gets worse during the day. To that I
    >>> ask a question: Are the server(s) more utilized during the day? If
    >>> so, would the gurus consider lost interrupts a possibility? Looks
    >>> like CENTos uses the 2.6.x kernels which some have mentioned had
    >>> trouble at least at some point in past.
    >>>
    >>> I mainly mention this because this has come up as a possibility
    >>> several times over the previous months, and I was wondering if there
    >>> is a way to diagnose this problem, either with NTP tools, or using
    >>> OS tools.
    >>>

    >>
    >> Lost interrupts result in the local clock being slow with respect to
    >> the server. The server will fall behind, step in the positive
    >> direction, fall behind again, step, etc. This seems to be a problem
    >> mostly with Linux systems that update the clock at frequencies greater
    >> than 100 Hz.
    >> Some systems can set the update frequency to 250 or 1000 Hz and those
    >> that do so have been known to exhibit this problem.

    >
    >
    > Where would I check on the clock update frequency?
    >


    There is a kernel parameter called HZ. Check its value. If the value
    is greater than 100 try changing the value to 100.


  7. Re: Getting good NTP tracking


    "Eino-Ville Talvala" wrote:
    > Richard B. Gilbert wrote:
    >> Charles Allen wrote:
    >>
    >>> I've lost track of who's said what, but at some point the original
    >>> poster mentioned that the offset gets worse during the day. To that I
    >>> ask a question: Are the server(s) more utilized during the day? If
    >>> so, would the gurus consider lost interrupts a possibility? Looks
    >>> like CENTos uses the 2.6.x kernels which some have mentioned had
    >>> trouble at least at some point in past.
    >>>
    >>> I mainly mention this because this has come up as a possibility
    >>> several times over the previous months, and I was wondering if there
    >>> is a way to diagnose this problem, either with NTP tools, or using
    >>> OS tools.
    >>>

    >>
    >> Lost interrupts result in the local clock being slow with respect to the
    >> server. The server will fall behind, step in the positive direction,
    >> fall behind again, step, etc. This seems to be a problem mostly with
    >> Linux systems that update the clock at frequencies greater than 100 Hz.
    >> Some systems can set the update frequency to 250 or 1000 Hz and those
    >> that do so have been known to exhibit this problem.

    >
    > Where would I check on the clock update frequency?
    >

    You can cat /proc/interrupts and look for the update rate of int0. This is
    the timer.

    Karel Sandler



  8. Re: Getting good NTP tracking

    Karel Sandler wrote:
    > "Eino-Ville Talvala" wrote:
    >> Richard B. Gilbert wrote:
    >>> Charles Allen wrote:
    >>>
    >>>> I've lost track of who's said what, but at some point the original
    >>>> poster mentioned that the offset gets worse during the day. To that I
    >>>> ask a question: Are the server(s) more utilized during the day? If
    >>>> so, would the gurus consider lost interrupts a possibility? Looks
    >>>> like CENTos uses the 2.6.x kernels which some have mentioned had
    >>>> trouble at least at some point in past.
    >>>>
    >>>> I mainly mention this because this has come up as a possibility
    >>>> several times over the previous months, and I was wondering if there
    >>>> is a way to diagnose this problem, either with NTP tools, or using
    >>>> OS tools.
    >>>>
    >>> Lost interrupts result in the local clock being slow with respect to the
    >>> server. The server will fall behind, step in the positive direction,
    >>> fall behind again, step, etc. This seems to be a problem mostly with
    >>> Linux systems that update the clock at frequencies greater than 100 Hz.
    >>> Some systems can set the update frequency to 250 or 1000 Hz and those
    >>> that do so have been known to exhibit this problem.

    >> Where would I check on the clock update frequency?
    >>

    > You can cat /proc/interrupts and look for the update rate of int0. This is
    > the timer.
    >
    > Karel Sandler
    >
    >


    Ok, I did
    cat /proc/interrupts; sleep 1; cat /proc/interrupts
    and subtracted the first INT0 value from the second. Result = 1004.

    Looks like it's running at a kHz. Kernel recompile, here I come...


+ Reply to Thread