Question about ntp log messages and logging interval - NTP

This is a discussion on Question about ntp log messages and logging interval - NTP ; Greetings - I am using NTP on a fully up to date RHEL3 system (Dell PE2600 hardware). I use a very basic configuration file (see below) and also use the North America NTP pool servers. Since I got ntp running ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Question about ntp log messages and logging interval

  1. Question about ntp log messages and logging interval

    Greetings -

    I am using NTP on a fully up to date RHEL3 system (Dell PE2600 hardware). I
    use a very basic configuration file (see below) and also use the North
    America NTP pool servers. Since I got ntp running properly (I think) about
    two weeks ago, I notice a lot of ntp information in my log file (see log
    snippet below).

    1. I am wondering if this is an indication of a properly (or improperly)
    running ntp system?
    2. If this logging is normal, are there any recommendations for how I can
    reduce the amount of logging?
    3. How do I find out what the standard polling interval is, and how would I
    reduce the interval if I wanted to?
    Thanks.

    #/etc/ntp.conf
    server 0.us.pool.ntp.org
    server 1.us.pool.ntp.org
    server 2.us.pool.ntp.org
    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /var/lib/ntp/drift

    # ntpq -p
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ===
    LOCAL(0) LOCAL(0) 10 l 18 64 377 0.000 0.000
    0.015
    *dns01.flame.org clock.xmission. 2 u 19 64 377 73.882 8.660
    42.399
    +216-136-10-198. ns.nts.umn.edu 3 u 30 64 377 112.790 9.468
    48.783
    +sfobug.org 97.226.103.255 2 u 16 64 377 113.669 15.344
    40.253

    ********* /var/log/messages ***********
    Sep 10 04:46:26 bison ntpd[20484]: time reset 0.842745 s
    Sep 10 04:46:26 bison ntpd[20484]: synchronisation lost
    Sep 10 05:25:02 bison ntpd[20484]: time reset 0.275572 s
    Sep 10 05:25:02 bison ntpd[20484]: synchronisation lost
    Sep 10 05:52:10 bison ntpd[20484]: time reset 1.007164 s
    Sep 10 05:52:10 bison ntpd[20484]: synchronisation lost
    Sep 10 06:42:48 bison ntpd[20484]: time reset 0.381250 s
    Sep 10 06:42:48 bison ntpd[20484]: synchronisation lost
    Sep 10 07:31:07 bison ntpd[20484]: time reset 0.541173 s
    Sep 10 07:31:07 bison ntpd[20484]: synchronisation lost
    Sep 10 08:18:24 bison ntpd[20484]: time reset 0.633675 s
    Sep 10 08:18:24 bison ntpd[20484]: synchronisation lost
    Sep 10 09:01:28 bison ntpd[20484]: time reset 0.433766 s
    Sep 10 09:01:28 bison ntpd[20484]: synchronisation lost
    Sep 10 09:23:06 bison ntpd[20484]: time reset 0.224851 s
    Sep 10 09:23:06 bison ntpd[20484]: synchronisation lost
    Sep 10 09:43:50 bison ntpd[20484]: time reset 0.452334 s
    Sep 10 09:43:50 bison ntpd[20484]: synchronisation lost
    Sep 10 10:36:33 bison ntpd[20484]: time reset 0.582234 s
    Sep 10 10:36:33 bison ntpd[20484]: synchronisation lost
    Sep 10 11:28:58 bison ntpd[20484]: time reset 0.432536 s
    Sep 10 11:28:58 bison ntpd[20484]: synchronisation lost
    Sep 10 11:48:37 bison ntpd[20484]: time reset 0.591722 s
    Sep 10 11:48:37 bison ntpd[20484]: synchronisation lost
    Sep 10 12:31:38 bison ntpd[20484]: time reset 0.697608 s
    Sep 10 12:31:38 bison ntpd[20484]: synchronisation lost
    Sep 10 13:11:33 bison ntpd[20484]: time reset 0.640630 s
    Sep 10 13:11:33 bison ntpd[20484]: synchronisation lost
    Sep 10 13:56:57 bison ntpd[20484]: time reset 0.967973 s
    Sep 10 13:56:57 bison ntpd[20484]: synchronisation lost
    Sep 10 14:48:37 bison ntpd[20484]: time reset 0.928340 s
    Sep 10 14:48:37 bison ntpd[20484]: synchronisation lost


    Jeff Boyce
    www.meridianenv.com

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


  2. Re: Question about ntp log messages and logging interval

    Jeff Boyce wrote:
    > Greetings -
    >
    > I am using NTP on a fully up to date RHEL3 system (Dell PE2600
    > hardware). I use a very basic configuration file (see below) and also
    > use the North America NTP pool servers. Since I got ntp running
    > properly (I think) about two weeks ago, I notice a lot of ntp
    > information in my log file (see log snippet below).
    >
    > 1. I am wondering if this is an indication of a properly (or improperly)
    > running ntp system?
    > 2. If this logging is normal, are there any recommendations for how I
    > can reduce the amount of logging?
    > 3. How do I find out what the standard polling interval is, and how
    > would I reduce the interval if I wanted to?
    > Thanks.
    >
    > #/etc/ntp.conf
    > server 0.us.pool.ntp.org
    > server 1.us.pool.ntp.org
    > server 2.us.pool.ntp.org
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /var/lib/ntp/drift
    >
    > # ntpq -p
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ===
    > LOCAL(0) LOCAL(0) 10 l 18 64 377 0.000 0.000 0.015
    > *dns01.flame.org clock.xmission. 2 u 19 64 377 73.882 8.660
    > 42.399
    > +216-136-10-198. ns.nts.umn.edu 3 u 30 64 377 112.790 9.468
    > 48.783
    > +sfobug.org 97.226.103.255 2 u 16 64 377 113.669 15.344
    > 40.253
    >
    > ********* /var/log/messages ***********
    > Sep 10 04:46:26 bison ntpd[20484]: time reset 0.842745 s
    > Sep 10 04:46:26 bison ntpd[20484]: synchronisation lost



    That does not look like a happy system to me! Your ntpq "banner" shows
    high values of jitter and long round trip delays. Since you are using
    pool servers, this is not exactly under your control but it is not good.
    The best servers are those close to you in "net space" because the
    error in transmitting time from server to client is limited to one half
    the round trip delay. It is usually much less than that but can't
    possibly be greater.

    The high jitter figures say that, if one of those servers were to send
    you a packet every second, the packets would not arrive at exact one
    second intervals. It's highly improbable that they would in any case
    but your internet connection seems to be introducing quite a bit of
    randomness in the transmission times!

    What can you do? Try to find a server or two with a round trip delay
    less than twenty milliseconds. Servers should be physically close to
    you; if you are in Los Angeles, don't consider servers in New York City!
    It may not be possible to find better servers than the ones you are
    using; good servers are in short supply! If you really need, or want,
    precise time you could do as I and many others have done; buy a GPS
    timing receiver and operate your own stratum one server. Or try a
    better internet connection.

  3. Re: Question about ntp log messages and logging interval

    In article ,
    Richard B. Gilbert wrote:
    > Jeff Boyce wrote:
    >
    > > 1. I am wondering if this is an indication of a properly (or improperly)
    > > running ntp system?


    Time steps in the same direction are an indication of a failing system.
    Either, your crystal is out by more than 500ppm, or, more likely,
    especially for Red Hat, is that you are losing clock interrupts. A
    contributory factor tends to be the use of HZ=1000 and IDE device
    drivers with interrupt latencies of more than 1ms. It is strongly
    reccommended that HZ be no more than 100.

    > > 3. How do I find out what the standard polling interval is, and how
    > > would I reduce the interval if I wanted to?


    The poll column in your ntpq output. On a system that is working well,
    this will soon reach 1024. Currently you are showing the minimum
    end of the normal range, which would normally only be the case during
    startup. You shouldn't change the limit values and the system will
    choose the optimum value within that range. A normally operating
    ntpd will never make abrupt time steps and using too short a poll
    interval will simply cause the phase to wander a lot faster. ntpd
    attempts to anticipate errors, rather than wipe them out at each poll.

    Reducing the poll interval below the current one may get you barred from
    the servers. Typically polling at an interval of less than 1 minute
    is considered abuse of the server.

    > That does not look like a happy system to me! Your ntpq "banner" shows
    > high values of jitter and long round trip delays. Since you are using


    These are not causing the problem and the jitter may be an effect.
    Without knowing the communication hardware, it is not possible to say
    that the delays are excessive, e.g. they are better than can be
    achieved using high speed modems.

    However if we are to air our pet themes on bad configurations, I would
    also ask why the local clock driver is configured. This should only be
    configured on servers and only if one understands why one is doing it.
    On a client, it does nothing useful at all. On a server, it may result
    in bad times seeming good.

    > second intervals. It's highly improbable that they would in any case
    > but your internet connection seems to be introducing quite a bit of
    > randomness in the transmission times!


    I believe the recent time step could also cause a high jitter value.

    > What can you do? Try to find a server or two with a round trip delay
    > less than twenty milliseconds. Servers should be physically close to


    There's no point in doing any of this until he has a stable lock on
    the servers he is currently using, which probably means rebuilding the
    kernel with a sensible HZ value, but may mean replacing the mother board.
    The delays shown in the ntpq snapshot are not enough to cause steps in
    their own right.

  4. Re: Question about ntp log messages and logging interval

    On Tue, 12 Sep 2006, David Woolley wrote:
    > In article ,
    > Richard B. Gilbert wrote:
    >> Jeff Boyce wrote:
    >>
    >>> 1. I am wondering if this is an indication of a properly (or improperly)
    >>> running ntp system?

    >
    > Time steps in the same direction are an indication of a failing system.
    > Either, your crystal is out by more than 500ppm, or, more likely,
    > especially for Red Hat, is that you are losing clock interrupts. A
    > contributory factor tends to be the use of HZ=1000 and IDE device
    > drivers with interrupt latencies of more than 1ms. It is strongly
    > reccommended that HZ be no more than 100.


    I can expand on this comment. There are a couple ways to check what your
    HZ value is set to if you don't know it.

    1. The easy way: check /proc/config.gz

    If you have the appropriate support in the kernel, this file will show
    what options were used to compile the kernel. Check for HZ. Here's an
    example on my Linux system:

    ~> gzip -dc /proc/config.gz | grep HZ
    # CONFIG_HZ_100 is not set
    CONFIG_HZ_250=y
    # CONFIG_HZ_1000 is not set
    CONFIG_HZ=250

    So my HZ is 250.

    2. If you don't have that, check your timer interrupts.

    This should always work, check the timing on your timer interrupts.

    ~> grep timer /proc/interrupts ; sleep 30; grep timer
    /proc/interrupts
    0: 146358116 IO-APIC-edge timer
    0: 146365617 IO-APIC-edge timer
    ~> bc
    146365617-146358116
    7501
    ../30
    250

    Both methods come up with 250.


    Finally, I thought there was an issue where when ntp is compiled on Linux,
    it looks
    up the value of HZ in the kernel headers. So if ntp was compiled on a
    machine with a different value of HZ than the machine you run it on, it
    won't work right. I don't know this for a fact, it's something I thought
    I heard before.


  5. Re: Question about ntp log messages and logging interval

    Richard B. Gilbert wrote:
    > What can you do? Try to find a server or two with a round trip delay
    > less than twenty milliseconds. Servers should be physically close to
    > you; if you are in Los Angeles, don't consider servers in New York City!
    > It may not be possible to find better servers than the ones you are
    > using; good servers are in short supply! If you really need, or want,
    > precise time you could do as I and many others have done; buy a GPS
    > timing receiver and operate your own stratum one server. Or try a
    > better internet connection.


    What about configuring (3) from the pool (as he's doing) and picking one
    from the Stratum 2 listing over at ntp.isc.org? That would give a
    pretty good handpicked server combined with 3 random servers from the pool.

    http://ntp.isc.org/bin/view/Servers/...TwoTimeServers

    (Being careful to follow the access policy and rules of engagement, of
    course.)

  6. Re: Question about ntp log messages and logging interval

    Thomas Harold wrote:

    > Richard B. Gilbert wrote:
    >
    >> What can you do? Try to find a server or two with a round trip delay
    >> less than twenty milliseconds. Servers should be physically close to
    >> you; if you are in Los Angeles, don't consider servers in New York City!
    >> It may not be possible to find better servers than the ones you are
    >> using; good servers are in short supply! If you really need, or want,
    >> precise time you could do as I and many others have done; buy a GPS
    >> timing receiver and operate your own stratum one server. Or try a
    >> better internet connection.

    >
    >
    > What about configuring (3) from the pool (as he's doing) and picking one
    > from the Stratum 2 listing over at ntp.isc.org? That would give a
    > pretty good handpicked server combined with 3 random servers from the pool.
    >
    > http://ntp.isc.org/bin/view/Servers/...TwoTimeServers
    >
    > (Being careful to follow the access policy and rules of engagement, of
    > course.)


    A good approach. The pool seems to have been intended to be used in
    much this way; to supplement your carefully chosen servers.

+ Reply to Thread