NTP 4.2.2p4 loopstats - NTP

This is a discussion on NTP 4.2.2p4 loopstats - NTP ; I just upgraded my old Red Hat 9 box from 4.2.0 to 4.2.2p4. The field in loopstats that formerly reported the 'jitter' value now appears to report 'noise' instead. Is this a bug or a feature, and can someone point ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: NTP 4.2.2p4 loopstats

  1. NTP 4.2.2p4 loopstats

    I just upgraded my old Red Hat 9 box from 4.2.0 to 4.2.2p4. The field
    in loopstats that formerly reported the 'jitter' value now appears to
    report 'noise' instead.
    Is this a bug or a feature, and can someone point me to a simple
    definition of noise?

    TIA,
    jg

  2. Re: NTP 4.2.2p4 loopstats

    jg,

    The source and interpretation of the loopstats data have not changed in
    several years. The fields in order are MJD, seconds of the day, offset
    (s), frequency (PPM), jitter (s), wander/stability (PPM) and time
    constant/poll interval (log2 s). If you are using a distribution not
    from here, anything goes.

    Note the statistics from the ntpq rv command, which has for a long time
    showed stability/wander and noise. There is a technical reason for this,
    but a careful explanation would bore you to tears. Someday all this
    should be rationalized with respect to the reference documentation.

    Dave

    jg wrote:

    > I just upgraded my old Red Hat 9 box from 4.2.0 to 4.2.2p4. The field
    > in loopstats that formerly reported the 'jitter' value now appears to
    > report 'noise' instead.
    > Is this a bug or a feature, and can someone point me to a simple
    > definition of noise?
    >
    > TIA,
    > jg


  3. Re: NTP 4.2.2p4 loopstats

    David,

    Many thanks for the prompt reply.

    Since this was not an intentional change, I suspect something went awry
    in my build process.

    Below is the output of ntpq -c rv:

    assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
    version="ntpd 4.2.2p4@1.1585 Sat Nov 4 15:04:11 UTC 2006 (1)",
    processor="i686", system="Linux/2.4.20-31.9", leap=00, stratum=2,
    precision=-19, rootdelay=61.646, rootdispersion=62.344, peer=12046,
    refid=18.26.4.105,
    reftime=c8f90653.d1be3eb7 Sun, Nov 5 2006 19:54:43.819, poll=10,
    clock=c8f90913.d0228a6a Sun, Nov 5 2006 20:06:27.813, state=4,
    offset=-15.298, frequency=-4.674, jitter=15.307, noise=4.414,
    stability=0.021

    and the relevant line from loopstats:

    54045 3283.819 -0.015298000 -4.674 0.004414435 0.020715 10

    The tarball was downloaded from ntp.isc.org on 11/4, and was built with
    no configure options.

    I'll try another compile when time permits and see what happens.

    Thanks,

    jg


    David L. Mills wrote:
    > jg,
    >
    > The source and interpretation of the loopstats data have not changed in
    > several years. The fields in order are MJD, seconds of the day, offset
    > (s), frequency (PPM), jitter (s), wander/stability (PPM) and time
    > constant/poll interval (log2 s). If you are using a distribution not
    > from here, anything goes.
    >
    > Note the statistics from the ntpq rv command, which has for a long time
    > showed stability/wander and noise. There is a technical reason for this,
    > but a careful explanation would bore you to tears. Someday all this
    > should be rationalized with respect to the reference documentation.
    >
    > Dave
    >
    > jg wrote:
    >
    >> I just upgraded my old Red Hat 9 box from 4.2.0 to 4.2.2p4. The field
    >> in loopstats that formerly reported the 'jitter' value now appears to
    >> report 'noise' instead.
    >> Is this a bug or a feature, and can someone point me to a simple
    >> definition of noise?
    >>
    >> TIA,
    >> jg


  4. Re: NTP 4.2.2p4 loopstats

    >>> In article , John Gill writes:

    John> The tarball was downloaded from ntp.isc.org on 11/4, and was built
    John> with no configure options.

    ntp.isc.org does not have any downloads on it - the pages there point to the
    UDel download area.

    Also notice this line from the NEWS file for ntp-dev:

    * [Bug 666] ntpq opeers displays jitter rather than dispersion.

    so http://bugs.ntp.isc.org/666 will have more information about this, in
    case it might be relevant.

    H

  5. Re: NTP 4.2.2p4 loopstats

    On 2006-11-06, Harlan Stenn wrote:

    >>>> In article , John Gill
    >>>> writes:

    >
    >> The tarball was downloaded from ntp.isc.org on 11/4, and was built
    >> with no configure options.

    >
    > ntp.isc.org does not have any downloads on it - the pages there point
    > to the UDel download area.


    I've added some notices to clarify this fact.

    It should be noted that the target URL has always been clearly displayed
    on the download jump pages.

    > Also notice this line from the NEWS file for ntp-dev:
    >
    > * [Bug 666] ntpq opeers displays jitter rather than dispersion.
    >
    > so http://bugs.ntp.isc.org/666 will have more information about this,
    > in case it might be relevant.


    The complete listing for any bug shown in the release announcement
    includes the bug URL:

    | * [Bug NNN] bug description
    | http://bugs.ntp.isc.org/NNN

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

  6. Re: NTP 4.2.2p4 loopstats

    Harlan,

    As you know, I have no faith whatsoever in what ntpdc claims are
    performance statistics. I've been trying to deprecate that program for
    years, as it uses ancient and outdated state variables. I do stand by
    the ntpq statistics, which have been carefully updated over the years.
    Maybe somebody changed the display from dispersion to jitter, but this
    would be at best misleading.

    I do see the op command using ntpq is misleading. The heading says
    dispersion but the value actually displayed is jitter. The op command
    should be deprecated, as it was added long ago with mistaken zeal. There
    might be more abuse in those commands; the only ones I watch carefully
    are the rv, as and pe commands.

    Dave

    Harlan Stenn wrote:

    >>>>In article , John Gill writes:

    >
    >
    > John> The tarball was downloaded from ntp.isc.org on 11/4, and was built
    > John> with no configure options.
    >
    > ntp.isc.org does not have any downloads on it - the pages there point to the
    > UDel download area.
    >
    > Also notice this line from the NEWS file for ntp-dev:
    >
    > * [Bug 666] ntpq opeers displays jitter rather than dispersion.
    >
    > so http://bugs.ntp.isc.org/666 will have more information about this, in
    > case it might be relevant.
    >
    > H


  7. Re: NTP 4.2.2p4 loopstats

    Wandering back to jg's original question...

    It appears that the jitter field which gets written to loopstats
    changed considerably between 4.2.0 and 4.2.2.

    The new value, in the global variable clock_jitter, is calculated from
    (last offset - current offset) rather than from the current offset as
    in 4.2.0.
    This new value is displayed by ntpq rv as "noise".

    The old value is still around in the global sys_jitter. ntpq still
    displays this value as "jitter" in 4.2.2.
    The sys_jitter value still gets updated, but not by ntp_loopfilter
    anymore - which only updates clock_jitter.

    This is significant to anyone who post-processes loopstats, as the new
    values are typically smaller in magnitude.
    I can't find anything about it in the bugs, docs, or mailing list.
    Maybe I'm just not finding it.

    A quick fix (...well, a quick ugly hack actually...), for anyone who's
    loopstats post-processing has been disrupted with 4.2.2, is to change
    the calls in ntpd/ntp_loopfilter.c to pass sys_jitter instead of
    clock_jitter to the 'record_loop_stats' function.

    Note that you probably don't want to change *anything* else in
    ntp_loopfilter - just the number which gets written to loopstats, lest
    you disrupt the calculation of poll interval, etc.

    -tom-


  8. Re: NTP 4.2.2p4 loopstats

    Tom,

    First, I believe Dave has good reasons for making these sort of changes.

    Second, I agree with you that making these changes messes people up.

    I would like to find a way to accomodate both changing the "data sources"
    and also performing data analysis on the "different flavors" of logfiles.

    - if anybody is interested in volunteering to work on this problem
    please let me know.

    I see 2 phases for this work:

    - designing a mechanism to handle/report/analyze the data
    - being available to watch for changes from Dave and "handling" them
    with the mechanism from "phase 1"

    and I'd be happy to see volunteers for either/both of these phases.

    I've started http://ntp.isc.org/Dev/StatisticsFileIssues as a place to
    discuss and evolve a solution to this problem.

    H

  9. Re: NTP 4.2.2p4 loopstats

    re: "I believe Dave has good reasons for making these sort of changes"

    Absolutely! Me too!

    That's why I urged no other changes besides what goes into loopstats.

    Let's not overstate the problem. A "few" people might need to adjust
    to the change in the data files. In this case, a bit of an explanation
    in the release notes and docs might have been good enough.

    In hindsight: adding clock_jitter as an eighth field - leaving the
    other seven fields intact - might also have been a nice choice, but
    only because sys_jitter is still available.

    As it is, any folks who seriously post-process loopstats probably won't
    balk at a small code-change to buy them a little more time to adapt to
    the new stats.

    I'm not sure if you really want to get into data analysis on log files.
    That would likely be a messy business. Everyone probably does it
    differently. I'd hate to see any NTP development effort redirected
    towards data-analysis at the expense of time-keeping.

    Just my 2 cents worth...

    -tom-


  10. Re: NTP 4.2.2p4 loopstats

    TomD,

    I haven't changed the statistics in a rather long time, although my
    timescale and the timescale of the distributions might not coincide. The
    statistics on jitter are rather intricate. In one sense the combined
    jitter weighted by the combined metric is valid and in the other what is
    claimed to be the selection jitter is the other. Both are reported in
    the rv statistics, although a case can be made for either one as the
    most important. Frankly, this represents a case for splitting hairs that
    is not really a sign of the times.

    Having said that, the loopstats have not changed in several years.

    Dave

    TomD wrote:
    > Wandering back to jg's original question...
    >
    > It appears that the jitter field which gets written to loopstats
    > changed considerably between 4.2.0 and 4.2.2.
    >
    > The new value, in the global variable clock_jitter, is calculated from
    > (last offset - current offset) rather than from the current offset as
    > in 4.2.0.
    > This new value is displayed by ntpq rv as "noise".
    >
    > The old value is still around in the global sys_jitter. ntpq still
    > displays this value as "jitter" in 4.2.2.
    > The sys_jitter value still gets updated, but not by ntp_loopfilter
    > anymore - which only updates clock_jitter.
    >
    > This is significant to anyone who post-processes loopstats, as the new
    > values are typically smaller in magnitude.
    > I can't find anything about it in the bugs, docs, or mailing list.
    > Maybe I'm just not finding it.
    >
    > A quick fix (...well, a quick ugly hack actually...), for anyone who's
    > loopstats post-processing has been disrupted with 4.2.2, is to change
    > the calls in ntpd/ntp_loopfilter.c to pass sys_jitter instead of
    > clock_jitter to the 'record_loop_stats' function.
    >
    > Note that you probably don't want to change *anything* else in
    > ntp_loopfilter - just the number which gets written to loopstats, lest
    > you disrupt the calculation of poll interval, etc.
    >
    > -tom-
    >


  11. Re: NTP 4.2.2p4 loopstats

    TomD,

    What changes are you talking about? The loopstats have not changed in
    many years. They include the time and datestamp, the magnitude and
    deviation of both the time and frequency offset and the time constant
    (poll interval). There is not much else that can be reported about the
    clock discipline algorithm. This is the same data reported over two
    decades of loopstats recording. Am I missing something?

    The rv statistics have in fact changed in really minor ways; the clock
    discipline jitter has been separated from the selection jitter, but if
    this is important in your performance analysis, I would be truly surprised.

    Davd

    TomD wrote:

    > re: "I believe Dave has good reasons for making these sort of changes"
    >
    > Absolutely! Me too!
    >
    > That's why I urged no other changes besides what goes into loopstats.
    >
    > Let's not overstate the problem. A "few" people might need to adjust
    > to the change in the data files. In this case, a bit of an explanation
    > in the release notes and docs might have been good enough.
    >
    > In hindsight: adding clock_jitter as an eighth field - leaving the
    > other seven fields intact - might also have been a nice choice, but
    > only because sys_jitter is still available.
    >
    > As it is, any folks who seriously post-process loopstats probably won't
    > balk at a small code-change to buy them a little more time to adapt to
    > the new stats.
    >
    > I'm not sure if you really want to get into data analysis on log files.
    > That would likely be a messy business. Everyone probably does it
    > differently. I'd hate to see any NTP development effort redirected
    > towards data-analysis at the expense of time-keeping.
    >
    > Just my 2 cents worth...
    >
    > -tom-
    >


  12. Re: NTP 4.2.2p4 loopstats

    Dave,

    re: "the clock discipline jitter has been separated from the selection
    jitter"
    & "loopstats have not changed in many years"
    & "This is the same data reported over two decades"

    No problem with separating the two jitters - but it was a surprise that
    the loopstats jitter field switched to reporting only the new
    clock_jitter, rather than continuing to report sys_jitter starting with
    NTP 4.2.2.

    clock_jitter appears to be a 3rd derivative vs. sys_jitter which
    appears to be a 2nd derivative of the clock offset. Is that correct?

    Graphing the jitter value from loopstats shows a much smaller value
    starting with 4.2.2. It doesn't correspond clearly to real-world
    things like network load, as it did before the change. (although I
    haven't collected enough of the new 'jitter' values to be sure of this)

    -tom-

    p.s. This topic seems to have gotten out of hand. The original
    question was "did jitter in loopstats change" and "what's a simple
    definition of the new value".

    Well, at least we've answered jg's first question: 'Yes, but the old
    value is still available with a small code change.'

    I'm a little taken aback by all the other things this topic has
    meandered into: e.g. *what values ntpq displays, *what it calls them,
    *the ntpq op command, *the ntpq opeers value (bug 666), *ntpdc,
    *ntp.isc->udel download links, *the other loopstats fields, *projects
    to design new analysis mechanisms, etc. etc. etc. Yikes!


  13. Re: NTP 4.2.2p4 loopstats

    TomD,

    There are several jitter statistics now, including per-association
    jitter and system jitter. These statistics are averages of first-oder
    time differences. It became apparent that frequency differences are a
    valuable indicator of equipment malfunction, A/C failure and so on. I
    could have simply tacked on an additional field, but there would be many
    more guys than just you out for my scalp. The old statistic wasn't very
    useful anyway. Take it from me and my own monitoring stash that you
    really want the frequency differences, properly interpreted as wander or
    maybe noise, but not jitter in the normal techical interpretation.

    The intended interpretation of loopstats is, as the name suggests,
    watching the discipline loop time, time differences, frequency,
    frequency differences and time constant (poll interval). From long
    experience, these xstatistics are really what you need to know. Watch
    the ;noise over a day or two; see how exquisitly sensitive it is.

    Dave

    TomD wrote:
    > Wandering back to jg's original question...
    >
    > It appears that the jitter field which gets written to loopstats
    > changed considerably between 4.2.0 and 4.2.2.
    >
    > The new value, in the global variable clock_jitter, is calculated from
    > (last offset - current offset) rather than from the current offset as
    > in 4.2.0.
    > This new value is displayed by ntpq rv as "noise".
    >
    > The old value is still around in the global sys_jitter. ntpq still
    > displays this value as "jitter" in 4.2.2.
    > The sys_jitter value still gets updated, but not by ntp_loopfilter
    > anymore - which only updates clock_jitter.
    >
    > This is significant to anyone who post-processes loopstats, as the new
    > values are typically smaller in magnitude.
    > I can't find anything about it in the bugs, docs, or mailing list.
    > Maybe I'm just not finding it.
    >
    > A quick fix (...well, a quick ugly hack actually...), for anyone who's
    > loopstats post-processing has been disrupted with 4.2.2, is to change
    > the calls in ntpd/ntp_loopfilter.c to pass sys_jitter instead of
    > clock_jitter to the 'record_loop_stats' function.
    >
    > Note that you probably don't want to change *anything* else in
    > ntp_loopfilter - just the number which gets written to loopstats, lest
    > you disrupt the calculation of poll interval, etc.
    >
    > -tom-
    >


  14. Re: NTP 4.2.2p4 loopstats

    Harlan,

    If there are volunteers with spare cycles, I would much rather they spin
    on the new code now covered in dust.

    What you are suggesting is not a trivial project and I've been there
    myself. See the (broken) scripts in ./scripts/stats. See also the
    systats monitor data, which is intended for managers like NIST and USNO.

    You should know that, in the early days of the Internet, DARPA tasked
    BBN to write an AI program that watched ARPAnet for breaks and squalls.
    They spent a lot of money on it, but came away with the conclusion the
    best I to do that had ears and eyes, a nose and a network map
    surrounding the entire room overlayed with transparent plastic and crayons.

    Dave

    Harlan Stenn wrote:

    > Tom,
    >
    > First, I believe Dave has good reasons for making these sort of changes.
    >
    > Second, I agree with you that making these changes messes people up.
    >
    > I would like to find a way to accomodate both changing the "data sources"
    > and also performing data analysis on the "different flavors" of logfiles.
    >
    > - if anybody is interested in volunteering to work on this problem
    > please let me know.
    >
    > I see 2 phases for this work:
    >
    > - designing a mechanism to handle/report/analyze the data
    > - being available to watch for changes from Dave and "handling" them
    > with the mechanism from "phase 1"
    >
    > and I'd be happy to see volunteers for either/both of these phases.
    >
    > I've started http://ntp.isc.org/Dev/StatisticsFileIssues as a place to
    > discuss and evolve a solution to this problem.
    >
    > H


  15. Re: NTP 4.2.2p4 loopstats

    TomD,

    My apologies; I did change the jitter and noise statistics quite a while
    ago, but the interval between numbered versions overlapped the change.

    If you were making serious assumptions about sys_jitter and
    clock_jitter, be advised sys_jitter is not an effective diagnostic
    statistic. It is derived from the weighted average of the survivors
    jitter and the selection jitter (ntpq rv jitter). But, this is not
    indicative of the actual jitter seen by the discipline loop (ntpq rv
    noise), which is a much more sensitive indicator of loop dynamic
    performance. In addition, up until the time of the change, the jitter
    reported by the daemon and by the kernel were calculated differently.
    Now they are the same.

    Dave

    TomD wrote:

    > Dave,
    >
    > re: "the clock discipline jitter has been separated from the selection
    > jitter"
    > & "loopstats have not changed in many years"
    > & "This is the same data reported over two decades"
    >
    > No problem with separating the two jitters - but it was a surprise that
    > the loopstats jitter field switched to reporting only the new
    > clock_jitter, rather than continuing to report sys_jitter starting with
    > NTP 4.2.2.
    >
    > clock_jitter appears to be a 3rd derivative vs. sys_jitter which
    > appears to be a 2nd derivative of the clock offset. Is that correct?
    >
    > Graphing the jitter value from loopstats shows a much smaller value
    > starting with 4.2.2. It doesn't correspond clearly to real-world
    > things like network load, as it did before the change. (although I
    > haven't collected enough of the new 'jitter' values to be sure of this)
    >
    > -tom-
    >
    > p.s. This topic seems to have gotten out of hand. The original
    > question was "did jitter in loopstats change" and "what's a simple
    > definition of the new value".
    >
    > Well, at least we've answered jg's first question: 'Yes, but the old
    > value is still available with a small code change.'
    >
    > I'm a little taken aback by all the other things this topic has
    > meandered into: e.g. *what values ntpq displays, *what it calls them,
    > *the ntpq op command, *the ntpq opeers value (bug 666), *ntpdc,
    > *ntp.isc->udel download links, *the other loopstats fields, *projects
    > to design new analysis mechanisms, etc. etc. etc. Yikes!
    >


  16. Re: NTP 4.2.2p4 loopstats

    Dave,

    Understood, and I'll take volunteer help wherever I can get it.

    I think Sachin may be available to do some work soon, and if not I will
    start working on it after 4.2.4 is released (and I do a couple of other
    upgrades that should not take too long).

    H

  17. Re: NTP 4.2.2p4 loopstats

    And I thought I was asking such a simple question...

    Many thanks to all who took the time to enlighten me.

    For the record, TomD's patch works well. As to whether sys_jitter or
    clock_jitter is a better indicator of performance, I am certainly not
    going to presume to differ with those far more qualified than I.

    jg

    David L. Mills wrote:
    > TomD,
    >
    > There are several jitter statistics now, including per-association
    > jitter and system jitter. These statistics are averages of first-oder
    > time differences. It became apparent that frequency differences are a
    > valuable indicator of equipment malfunction, A/C failure and so on. I
    > could have simply tacked on an additional field, but there would be many
    > more guys than just you out for my scalp. The old statistic wasn't very
    > useful anyway. Take it from me and my own monitoring stash that you
    > really want the frequency differences, properly interpreted as wander or
    > maybe noise, but not jitter in the normal techical interpretation.
    >
    > The intended interpretation of loopstats is, as the name suggests,
    > watching the discipline loop time, time differences, frequency,
    > frequency differences and time constant (poll interval). From long
    > experience, these xstatistics are really what you need to know. Watch
    > the ;noise over a day or two; see how exquisitly sensitive it is.
    >
    > Dave
    >
    > TomD wrote:
    >> Wandering back to jg's original question...
    >>
    >> It appears that the jitter field which gets written to loopstats
    >> changed considerably between 4.2.0 and 4.2.2.
    >>
    >> The new value, in the global variable clock_jitter, is calculated from
    >> (last offset - current offset) rather than from the current offset as
    >> in 4.2.0.
    >> This new value is displayed by ntpq rv as "noise".
    >>
    >> The old value is still around in the global sys_jitter. ntpq still
    >> displays this value as "jitter" in 4.2.2.
    >> The sys_jitter value still gets updated, but not by ntp_loopfilter
    >> anymore - which only updates clock_jitter.
    >>
    >> This is significant to anyone who post-processes loopstats, as the new
    >> values are typically smaller in magnitude.
    >> I can't find anything about it in the bugs, docs, or mailing list.
    >> Maybe I'm just not finding it.
    >>
    >> A quick fix (...well, a quick ugly hack actually...), for anyone who's
    >> loopstats post-processing has been disrupted with 4.2.2, is to change
    >> the calls in ntpd/ntp_loopfilter.c to pass sys_jitter instead of
    >> clock_jitter to the 'record_loop_stats' function.
    >>
    >> Note that you probably don't want to change *anything* else in
    >> ntp_loopfilter - just the number which gets written to loopstats, lest
    >> you disrupt the calculation of poll interval, etc.
    >>
    >> -tom-
    >>


  18. Not able to connect

    Been trying to get my PC to connect to an internet time server via ntpd.
    No luck thus far.

    OS - Linux, Fedora Core 5
    Connected to internet via ethernet to Actiontec DSL ethernet hub

    Have tried turning the Actiontec Firewall completely off and setting the
    Linux Firewall to allow TCP port 13.

    All attempts to connect to an NTP server fail.

    Any hints as to how to get ntp working and keeping the clock updated
    automatically?

    The following are excerpts from the file /var/log/messages:

    Nov 15 16:19:22 localhost ntpdate[2140]: can't find host time
    Nov 15 16:20:06 localhost ntpdate[2140]: no server suitable for
    synchronization found
    Nov 15 16:20:06 localhost ntpd[2155]: ntpd 4.2.0a@1.1196-r Thu May 11
    09:19:35 EDT 2006 (1)
    Nov 15 16:20:06 localhost ntpd[2155]: precision = 2.000 usec
    Nov 15 16:20:06 localhost ntpd[2155]: Listening on interface wildcard,
    0.0.0.0#123
    Nov 15 16:20:06 localhost ntpd[2155]: Listening on interface wildcard,
    ::#123
    Nov 15 16:20:06 localhost ntpd[2155]: Listening on interface lo,
    127.0.0.1#123
    Nov 15 16:20:06 localhost ntpd[2155]: Listening on interface eth0,
    192.168.1.64#123
    Nov 15 16:20:06 localhost ntpd[2155]: kernel time sync status 0040

    Nov 15 16:20:55 localhost ntpd[2155]: frequency initialized -336.519
    PPM from /var/lib/ntp/drift

    Nov 15 16:22:45 localhost ntpd[2155]: getaddrinfo: "time" invalid host
    address, ignored
    Nov 15 16:23:45 localhost ntpd[2155]: getaddrinfo: "time" invalid host
    address, ignored

    Nov 15 17:08:12 localhost ntpd[2155]: ntpd exiting on signal 15
    Nov 15 17:08:17 localhost ntpd_initres[2895]: parent died before we
    finished, exiting
    Nov 15 17:09:34 localhost ntpdate[3425]: can't find host time
    Nov 15 17:10:06 localhost ntpdate[3425]: can't find host time
    Nov 15 17:10:52 localhost ntpdate[3425]: no server suitable for
    synchronization found
    Nov 15 17:10:52 localhost ntpd[3477]: ntpd 4.2.0a@1.1196-r Thu May 11
    09:19:35 EDT 2006 (1)
    Nov 15 17:10:52 localhost ntpd[3477]: precision = 2.000 usec
    Nov 15 17:10:52 localhost ntpd[3477]: Listening on interface wildcard,
    0.0.0.0#123
    Nov 15 17:10:52 localhost ntpd[3477]: Listening on interface wildcard,
    ::#123
    Nov 15 17:10:52 localhost ntpd[3477]: Listening on interface lo,
    127.0.0.1#123
    Nov 15 17:10:52 localhost ntpd[3477]: Listening on interface eth0,
    192.168.1.64#123
    Nov 15 17:10:52 localhost ntpd[3477]: kernel time sync status 0040


    The following is the file /etc/ntp.conf file:

    # Permit time synchronization with our time source, but do not
    # permit the source to query or modify the service on this system.

    restrict default nomodify notrap noquery

    # Permit all access over the loopback interface. This could
    # be tightened as well, but to do so would effect some of
    # the administrative functions.
    restrict 127.0.0.1


    # -- CLIENT NETWORK -------
    # Permit systems on this network to synchronize with this
    # time service. Do not permit those systems to modify the
    # configuration of this service. Also, do not use those
    # systems as peers for synchronization.
    # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap


    # --- OUR TIMESERVERS -----
    server 0.pool.ntp.org
    server 1.pool.ntp.org
    server 2.pool.ntp.org


    # --- NTP MULTICASTCLIENT ---
    #multicastclient # listen on default 224.0.1.1
    # restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
    # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap



    # --- GENERAL CONFIGURATION ---
    #
    # Undisciplined Local Clock. This is a fake driver intended for backup
    # and when no outside source of synchronized time is available. The
    # default stratum is usually 3, but in this case we elect to use stratum
    # 0. Since the server line does not have the prefer keyword, this driver
    # is never used for synchronization, unless no other other
    # synchronization source is available. In case the local host is
    # controlled by some external source, such as an external oscillator or
    # another protocol, the prefer keyword would cause the local host to
    # disregard all other synchronization sources, unless the kernel
    # modifications are in use and declare an unsynchronized condition.
    #
    fudge 127.127.1.0 stratum 10

    #
    # Drift file. Put this in a directory which the daemon can write to.
    # No symbolic links allowed, either, since the daemon updates the file
    # by creating a temporary in the same directory and then rename()'ing
    # it to the file.
    #
    driftfile /var/lib/ntp/drift
    broadcastdelay 0.008

    #
    # Keys file. If you want to diddle your server at run time, make a
    # keys file (mode 600 for sure) and define the key number to be
    # used for making requests.
    #
    # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
    # systems might be able to reset your clock at will. Note also that
    # ntpd is started with a -A flag, disabling authentication, that
    # will have to be removed as well.
    #
    keys /etc/ntp/keys
    restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    restrict 129.6.15.28 mask 255.255.255.255 nomodify notrap noquery
    restrict 129.6.15.29 mask 255.255.255.255 nomodify notrap noquery
    server time
    restrict time mask 255.255.255.255 nomodify notrap noquery
    server time
    restrict time mask 255.255.255.255 nomodify notrap noquery
    server time-a.nist.gov
    restrict time-a.nist.gov mask 255.255.255.255 nomodify notrap noquery
    server time-b.nist.gov
    restrict time-b.nist.gov mask 255.255.255.255 nomodify notrap noquery
    #broadcastclient

    Any Ideas on how to get ntp to connect and maintain the clock???

  19. Re: Not able to connect

    On 2006-11-16, terrypearl wrote:

    > Been trying to get my PC to connect to an internet time server via ntpd.
    > No luck thus far.
    >
    > OS - Linux, Fedora Core 5
    > Connected to internet via ethernet to Actiontec DSL ethernet hub
    >
    > Have tried turning the Actiontec Firewall completely off and setting the
    > Linux Firewall to allow TCP port 13.


    NTP uses port 123/UDP



    > The following is the file /etc/ntp.conf file:


    I see nothing in here that would prevent ntpd from working once you have
    the correct port open.

    > restrict default nomodify notrap noquery


    This restriction line applies to all of your ntpd's "clients" and
    "servers". There is no need to specify explicit per host / subnet
    restrict lines unless you wish to modify this restriction.

    http://ntp.isc.org/Support/AccessRestrictions contains information about
    setting your ntpd restrictions.

    > restrict 127.0.0.1
    >
    > # --- OUR TIMESERVERS -----
    > server 0.pool.ntp.org
    > server 1.pool.ntp.org
    > server 2.pool.ntp.org


    If you append 'iburst' to these server lines you will speed up ntpd's
    initial synchronization from ~8 minutes to ~20 seconds.

    These pool server hostnames can resolve to serves located anywhere in
    the world. You may wish to restrict the pool to your geographic area.
    Please see http://ntp.isc.org/pool for more information.

    > fudge 127.127.1.0 stratum 10


    You have not told ntpd to _use_ the undisciplined local clock. To do so
    you have to include this server line:

    server 127.127.1.0

    There are really only two reasons to use the undisciplined local clock:

    1. You are serving time to others and need to be able to continue doing
    so even if you loose communication with your time sources (e.g. remote
    time servers or local ref-clocks).

    2. You are serving time to others in an isolated network.

    > driftfile /var/lib/ntp/drift
    > broadcastdelay 0.008


    You do not need to specify the broadcast delay unless this ntpd is
    operating as a broadcast client _and_ it is unable to calculate the
    delay itsself.

    > keys /etc/ntp/keys


    You have not completed the symmetric key configuration, so that keys
    line does nothing for you.

    > restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    > restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
    > restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery


    The restrictions for these hosts are redundant as they are the same as
    the default restriction.

    > restrict 129.6.15.28 mask 255.255.255.255 nomodify notrap noquery
    > restrict 129.6.15.29 mask 255.255.255.255 nomodify notrap noquery


    The restrictions for these hosts are redundant as they are the same as
    the default restriction.

    > server time
    > restrict time mask 255.255.255.255 nomodify notrap noquery
    > server time
    > restrict time mask 255.255.255.255 nomodify notrap noquery


    What's the point of the previous 4 lines? Do you have access to an NTP
    server named 'time.your.domain' ?

    > server time-a.nist.gov
    > restrict time-a.nist.gov mask 255.255.255.255 nomodify notrap noquery
    > server time-b.nist.gov
    > restrict time-b.nist.gov mask 255.255.255.255 nomodify notrap noquery


    These are Stratum-1 servers. Please check the the Rules of Engagement
    (http://ntp.isc.org/rules) and make sure that you meet the criteria for
    the direct use of Stratum-1 time servers. Unless you are supporting a
    large number of client systems you should be using Stratum-2 servers
    (http://ntp.isc.org/s2) and/or the NTP Pool (http://ntp.isc.org/pool).

    The comment about redundant restrictions also applies here.

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

  20. Re: Not able to connect

    terrypearl wrote:

    > Been trying to get my PC to connect to an internet time server via ntpd.
    > No luck thus far.
    >
    > OS - Linux, Fedora Core 5
    > Connected to internet via ethernet to Actiontec DSL ethernet hub
    >
    > Have tried turning the Actiontec Firewall completely off and setting the
    > Linux Firewall to allow TCP port 13.
    >



    I hope that "port 13" was a typo!!!! NTP uses port 123. If that's
    not open, ntpd won't work!!!!!!!!!!!!!

    You can use ntpdate to "ping" a server. It will set your clock unless
    you use the "-d" switch. If ntpd is running, you need to use "ntpdate
    -du" which will use a non-privileged port.

+ Reply to Thread
Page 1 of 2 1 2 LastLast