Re: Trace ntp sanity checks? - NTP

This is a discussion on Re: Trace ntp sanity checks? - NTP ; Hello Martin, i already recorded the output you asked me for some days ago: ntpq -p remote refid st t when poll reach delay offset jitter ================================================== ========================*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000 0.004 master1 10.212.70.11 4 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: Trace ntp sanity checks?

  1. Re: Trace ntp sanity checks?

    Hello Martin,

    i already recorded the output you asked me for some days ago:

    ntpq -p
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ========================*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
    0.004
    master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
    master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665

    (the high offset is because the ntp-client lost synchronization a long
    time ago)


    ntpq> rv 8773
    assID‡73 status14 reach, 1 event, event_reach,
    srcadr=master1, srcport3, dstadr=0.0.0.0,
    dstport3, leap\0, stratum=4, precision=0, rootdelay=0.000,
    rootdispersion=0.000, refid.248.128.74, reach77, unreach=0,
    hmode=8, pmode=5, hpoll=6, ppoll=6, flash\0 ok, keyid=0, ttl
    =0,
    offsetT9217.462, delay=0.447, dispersion™7.039, jitterX.874,
    reftimeÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
    orgÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
    recÊf7bfcb.44055fbb Wed, Nov 28 2007 11:22:03.265,
    xmtÊe54d0b.8746ed24 Wed, Nov 14 2007 11:31:39.528,
    filtdelay= 0.45 0.45 0.45 0.45 0.45 0.45 0.45
    0.45,
    filtoffset= 549217. 549210. 549199. 549186. 549169. 549153. 549132.
    549121.,
    filtdisp= 1000.48 1000.96 1001.44 1001.92 1002.40 1002.88 1003.36
    1003.84


    i already tried to interpret this, but the only thing i figured out is
    that the zero in 1014 means that the client is rejected because of
    failed sanity checks.

    many clients showing the problem are running ntp-version 4.2.0a@1.1196-r
    on linux.
    i once heard that the server is a Tardis product for windows - but i
    cannot supply details about that.

    the ntp-server and the network are not managed by myself.
    because of that i would like to have enough knowledge of ntp to analyze
    such problems on the client side (as far as possible).
    i had these problems quite frequently, sometimes often, sometimes not at
    all...

    is there a way to trace down which sanity-check failed?


    thanks a lot
    Frank


    -----Original Message-----
    From: DE/SYS Routing - Linux, Team

    Sent: Wednesday, December 05, 2007 11:50 AM
    To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph
    Subject: FW: Trace ntp sanity checks?


    -------------------------------------------
    From: questions-bounces+linux=stihl.de@lists.ntp.org on behalf of Martin
    Burnicki[SMTP:MARTIN.BURNICKI@MEINBERG.DE]
    Sent: Wednesday, December 05, 2007 11:32:04 AM
    To: questions@lists.ntp.org
    Subject: Re: Trace ntp sanity checks?
    Auto forwarded by a Rule

    Frank,

    linux@stihl.de wrote:
    > Hello,
    >


    > we are having problems to synchronize linux & aix ntp-clients to a
    > ntp-broadcastserver.
    >


    > ntp-broadcast-packets are received by the clients, but all servers are
    > rejected by the clients after a few minutes.
    >


    > we found out, that the ntp-servers do not pass the sanity-checks on

    the
    > clients and get probably rejected because of that.
    >


    > How can we further track down which of the sanity-checks fails and

    why...

    If the NTP on the client has been compiled with debug option then you
    can
    run ntpd with the -d option ans see what it prints on the console.

    Otherwise, if the broadcast server is listed in the output of "ntpq -p"
    you
    can see details of the server association using the following commands.

    Print billboard of the associations:

    # ntpq -p
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ===================*gateway.py.mein .GPSi. 1 u 34 64 377 0.148 -0.011
    0.362

    Find out the association IDs:

    # ntpq -c as

    ind assID status conf reach auth condition last_event cnt
    ================================================== ======1 41266 9614 yes yes none sys.peer reachable 1

    In this case the association ID is 41266. Use the ID to find more
    details on
    the association:

    # ntpq -c "rv 41266"
    assIDA266 status–14 reach, conf, sel_sys.peer, 1 event, event_reach,
    srcadr=gateway.py.meinberg.de, srcport3, dstadr2.16.3.27,
    dstport3, leap\0, stratum=1, precision=-18, rootdelay=0.000,
    rootdisp=0.580, refid=GPSi, reach77, unreach=0, hmode=3, pmode
    =4,
    hpoll=6, ppoll=6, flash\0 ok, keyid=0, ttl=0, offset=-0.659,
    delay=0.163, dispersion=2.055, jitter=0.307,
    reftimeË00fb6b.000192a7 Wed, Dec 5 2007 11:26:51.000,
    orgË00fb71.b05ff1d8 Wed, Dec 5 2007 11:26:57.688,
    recË00fb71.b0814599 Wed, Dec 5 2007 11:26:57.689,
    xmt\0000000.00000000 Thu, Feb 7 2036 7:28:16.000,
    filtdelay= 0.18 0.19 0.16 0.23 0.20 0.23 0.19
    0.21,
    filtoffset= -0.42 -0.61 -0.66 -0.76 -0.88 -1.04 -1.14
    -1.06,
    filtdisp= 0.01 1.00 1.97 2.96 3.92 4.90 5.86
    6.85

    You should not interpret the output above. It's just a quick test to
    show
    how to proceed.


    If you post your output of the ntpq -p and ntpq -c "rv ..." commands
    here
    then we may be able to help.

    And, the versions of NTP on the server and on the clients might be
    interesting ...

    Martin
    --

    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    __________________________________________________ _________________

    This E-Mail is confidential. If you are not the intended recipient, you must
    not copy, disclose or use its contents. If you have received it in error,
    please inform us immediately by return E-Mail and delete the document.


    Diese E-Mail ist vertraulich. Wenn Sie nicht der rechtmäßige Empfänge
    r sind,
    dürfen Sie den Inhalt weder kopieren, verbreiten noch benutzen. Sollten S
    ie
    diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns
    zurück und löschen sie anschließend.


    Cet e-mail est confidentiel. Si vous n'etes pas le destinataire de ce
    message, vous ne devez pas copier, divulguer ou utiliser le contenu. Si vous
    avez recu cet e-mail par erreur, veuillez nous informer en retournant ce
    message a l'expediteur et detruisez-le.


    Esta mensagem, e qualquer de seus anexos, eh confidencial e privilegiada.
    Caso voce nao seja o destinatario, nao esta autorizado a reproduzir ou
    divulgar a terceiros o conteudo desta mensagem e de qualquer anexo da mesma
    e deve apagar com os seus respectivos anexos.

    __________________________________________________ _________________

    ANDREAS STIHL AG & Co. KG
    Kommanditgesellschaft mit Sitz in Waiblingen, HRA 260269, Amtsgericht Stutt
    gart

    Persönlich haftende Gesellschafter: Hans Peter Stihl und STIHL Aktiengese
    llschaft
    mit Sitz in Waiblingen, HRB 263722, Amtsgericht Stuttgart
    Vorstand der STIHL AG: Dr. Bertram Kandziora (Vorstandsvorsitzender),

    Dr. Peter Dürolf, Jürgen Steinhauser, Wolfgang Zahn
    Vorsitzender des Aufsichtsrats der STIHL AG: Hans Peter Stihl

  2. Re: Trace ntp sanity checks?

    >>> In article <154E3348CEF56F4188CA1F05332CED20FA50AC@de00srvmes0 11r1.emea.dir>, linux@stihl.de writes:

    linux> ntpq -p

    remote refid st t when poll reach delay offset jitter
    ================================================== ========================
    *LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000 0.004
    master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
    master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665

    You are sync'd to your local machine, and your 2 "master" machines are now
    far enough out that your local ntpd will not talk to them.

    You have been thru:

    http://support.ntp.org/bin/view/Supp...YourNTPNetwork

    and

    http://support.ntp.org/bin/view/Support/ConfiguringNTP

    right?

    H
    --
    http://ntpforum.isc.org - be a member!

  3. Re: Trace ntp sanity checks?

    In article <154E3348CEF56F4188CA1F05332CED20FA50AC@de00srvmes0 11r1.emea.dir>,
    linux@stihl.de wrote:

    > *LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
    > 0.004


    One would normally not serve time from a machine synchronised by
    broadcasts. Defining a local clock driver serves no useful purpose
    on a pure client (and should only be done with full understanding on
    a server). Too many packaging of ntpd configure a local clock driver
    in their sample configuration.

    Problems arise if the local clock is seen as the best available time source,
    locally, or downstream. Both locally and downstream, the clock failure
    will never be detected.

    The software clock will retain is last known phase and frequency corrections,
    even if ntpd fails to get valid replies. Local clock is only used if it
    is important that downstream clients see the same, free running, time, rather
    than slowly diverge from each other.

    > master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790


    Note that you are halfway to the drop dead error. If ntpd accepts an
    offset less than twice this, it will commit suicide.


  4. Re: Trace ntp sanity checks?

    Too many packaging of ntpd configure a local clock driver
    >in their sample configuration.


    Does anybody know why that got started?

    What urban legend do we have to stomp out before that practice will go away?


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


  5. Re: Trace ntp sanity checks?

    Hal Murray wrote:
    > Too many packaging of ntpd configure a local clock driver
    >
    >>in their sample configuration.

    >
    >
    > Does anybody know why that got started?
    >
    > What urban legend do we have to stomp out before that practice will go away?
    >
    >


    It's no worse than the people who just want to "synchronize clocks to
    each other" without regard to what time it is. The local clock driver
    is harmless as long as people configure it to stratum 10!


  6. Re: Trace ntp sanity checks?

    On 2007-12-07, Hal Murray wrote:

    >ATTRIBUTION DELETED wrote:
    >
    >>Too many packaging of ntpd configure a local clock driver in their
    >>sample configuration.

    >
    > Does anybody know why that got started?


    The sample configuration files attempt to include as many configuration
    options as possible. Unfortunately there is often insufficient, or just
    plain misleading, explanation of what these options should be used for.

    > What urban legend do we have to stomp out before that practice will go
    > away?


    The problem is that the distribution does not contain good sample
    configuration files. There should be sample configurations for:

    Pool client
    Leaf node
    unicast
    broadcast
    multicast
    manycast
    LAN server
    unicast
    broadcast
    multicast
    manycast
    and so on.

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

  7. Re: Trace ntp sanity checks?

    In article <4758C2A7.9080307@comcast.net>,
    Richard B. Gilbert wrote:

    > The local clock driver
    > is harmless as long as people configure it to stratum 10!


    This very thread demonstrates a case where it wasn't harmless!

    What has happened here appears to be that it has provided a much more
    attractive indication of the time than proper time sources. I'm not
    exactly sure why that is in this case, but, in other cases people have
    had more local clock derived sources than real sources, and, because
    the reference implementation claims zero root delay and zero root
    dispersion (because it assumes that the local clock is being disciplined
    by some other means, rather than free running), an upstream local clock can
    have a very low apparent error band, so it can be quite difficult for other
    sources to fall within the same cluster.

    The other basic problem is that downstream nodes don't receive any indication
    that they are disconnected from real time, whereas an alarm condition
    would be signalled by a server without a local clock driver.

    Note that using stratum 10 doesn't prevent these problems, it simply
    stops nodes that more than about 2 hops downstream from having problems
    from that particular local clock driver; it limits the area subject to
    harm.

    As to the urban myth. Whilst a lot of it is simply copy and paste
    programming, I think there is a significant myth that, without the local
    clock driver, the software clock will revert to its natural frequency,
    when it loses all time sources.

+ Reply to Thread