Re: Trace ntp sanity checks? - NTP

This is a discussion on Re: Trace ntp sanity checks? - NTP ; Hi, thank you very much for your responses. summary: you see no reason, why a ntp-client that does not serve its time to someone else should have a local clock configured? did i get this right? i will change my ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Trace ntp sanity checks?

  1. Re: Trace ntp sanity checks?


    Hi,

    thank you very much for your responses.

    summary:
    you see no reason, why a ntp-client that does not serve its time to
    someone else should have a local clock configured?
    did i get this right?

    i will change my configuration and try that.

    does anyone of you have details regarding my original question:
    How can i find out which of the sanity-checks failed?



    regards
    Frank




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

    Sent: Friday, December 07, 2007 9:16 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
    david@ex.djwhome.demon.co.uk.invlid[...DEMON.CO.UK.IN
    VLID]
    Sent: Friday, December 07, 2007 8:56:31 AM
    To: questions@lists.ntp.org
    Subject: Re: Trace ntp sanity checks?
    Auto forwarded by a Rule

    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.

    _______________________________________________
    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?

    On 2007-12-07, linux@stihl.de wrote:

    > you see no reason, why a ntp-client that does not serve its time to
    > someone else should have a local clock configured?
    > did i get this right?


    The only reason to use the Undisciplined Local Clock (127.127.1.x) is on
    an ntpd which must be able to serve time to others even when there are
    no real time sources available.

    The Undiciplined Local Clock is not a time source and does nothing to
    keep ntpd synchronised.

    > does anyone of you have details regarding my original question:
    > How can i find out which of the sanity-checks failed?


    I don't think you can.

    > -----Original Message-----
    > [---=| TOFU protection by t-prot: 100 lines snipped |=---]


    Oh, that's what you were replying to.

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

  3. Re: Trace ntp sanity checks?

    Steve Kostecke wrote:
    >> does anyone of you have details regarding my original question:
    >> How can i find out which of the sanity-checks failed?

    >
    > I don't think you can.


    if the sanity-checks failed it should put out a hex value containing the
    errors detected. You then have to look at the code to see what those
    bits mean. We shoulf be making this easier. What was the error that you
    got? Sorry but I haven't been following this.

    Danny

  4. Re: Trace ntp sanity checks?

    Danny Mayer wrote:
    > Steve Kostecke wrote:
    >>> does anyone of you have details regarding my original question:
    >>> How can i find out which of the sanity-checks failed?

    >>
    >> I don't think you can.

    >
    > if the sanity-checks failed it should put out a hex value containing the
    > errors detected. You then have to look at the code to see what those
    > bits mean. We shoulf be making this easier. What was the error that you
    > got? Sorry but I haven't been following this.


    Shouldn't this be visible via the flash bits displayed by
    ntpq -c "rv " ?

    I had asked the OP to post the output of the command. However, the output
    was truncated. Here's a quote:
    > ntpq> rv 8773
    > assID?73 status 14 reach, 1 event, event_reach,
    > srcadrmaster1, srcport 3, dstadr0.0.0.0,
    > dstport 3, leap


    The rest of the output which should be including the "flash" bits is missing
    here.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread