why is this clock not even considered? - NTP

This is a discussion on why is this clock not even considered? - NTP ; Hi, See this: remote refid st t when poll reach delay offset jitter ================================================== ============================ +belle.intranet. 192.87.106.2 2 u 251 256 375 0.105 6.605 0.122 +thegateap.intra 192.87.106.2 2 u 106 256 277 1.250 6.193 0.150 *mauer.intranet. .DCFa. 1 u 253 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: why is this clock not even considered?

  1. why is this clock not even considered?

    Hi,

    See this:
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +belle.intranet. 192.87.106.2 2 u 251 256 375 0.105 6.605 0.122
    +thegateap.intra 192.87.106.2 2 u 106 256 277 1.250 6.193 0.150
    *mauer.intranet. .DCFa. 1 u 253 256 377 0.154 0.068 0.071
    -auth1.xs4all.nl 193.79.237.14 2 u 53 256 277 7.899 17.204 2.084
    +ntp1.nl.uu.net .GPS. 1 u 8 256 337 13.599 6.001 8.832
    -ntp3-rz.rrze.un .DCFp. 1 u 21 256 377 29.566 0.059 0.237
    +ntps1-1.cs.tu-b .PPS. 1 u 1043 256 360 29.793 7.204 0.097
    +chime1.surfnet. .GPS. 1 u 42 256 377 9.135 6.485 2.794
    SHM(0) .SHM. 0 l 11 64 377 0.000 -5.365 1.810

    Why is the '.SHM.'-clock not even considered? Because of the negative offset?


    Folkert van Heusden

    --
    MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
    kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
    view', vs. http://www.vanheusden.com/multitail/
    ----------------------------------------------------------------------
    Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

  2. Re: why is this clock not even considered?

    Folkert van Heusden wrote:
    > Hi,
    >
    > See this:
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > +belle.intranet. 192.87.106.2 2 u 251 256 375 0.105 6.605 0.122
    > +thegateap.intra 192.87.106.2 2 u 106 256 277 1.250 6.193 0.150
    > *mauer.intranet. .DCFa. 1 u 253 256 377 0.154 0.068 0.071
    > -auth1.xs4all.nl 193.79.237.14 2 u 53 256 277 7.899 17.204 2.084
    > +ntp1.nl.uu.net .GPS. 1 u 8 256 337 13.599 6.001 8.832
    > -ntp3-rz.rrze.un .DCFp. 1 u 21 256 377 29.566 0.059 0.237
    > +ntps1-1.cs.tu-b .PPS. 1 u 1043 256 360 29.793 7.204 0.097
    > +chime1.surfnet. .GPS. 1 u 42 256 377 9.135 6.485 2.794
    > SHM(0) .SHM. 0 l 11 64 377 0.000 -5.365 1.810
    >
    > Why is the '.SHM.'-clock not even considered? Because of the negative offset?
    >
    >
    > Folkert van Heusden


    Are you using the 'prefer' keyword with that configured server?

    --
    Dennis Hilberg, Jr. timekeeper(at)dennishilberg(dot)com
    NTP Server Information: http://saturn.dennishilberg.com/ntp.php

  3. Re: why is this clock not even considered?


    >Why is the '.SHM.'-clock not even considered? Because of the negative offset?


    Negative offsets are not a problem. They happen all the time.

    My guess is that something your new driver is setting up
    makes your clock look not-very-good. It's probably one of the
    obscure constants that aren't well documented.

    You might look at the code in gpsd. It's known to work.

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


  4. Re: why is this clock not even considered?

    Folkert,

    First, temporarily remove all but the SHM driver to simplify debugging.
    Then, look at the rv billoard for that association and note the flasher
    bits. Then, look at the peer_unfit() routine in ntp_proto.c. The
    comments detail the reasons for each bit. More information is in the
    specification document and the notes on debugging a radio clock in the
    documentation. The probable cause is dispersion too high or the noselect
    option is present. The prefer option has nothing to do with this.

    Dave

    Folkert van Heusden wrote:
    > Hi,
    >
    > See this:
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > +belle.intranet. 192.87.106.2 2 u 251 256 375 0.105 6.605 0.122
    > +thegateap.intra 192.87.106.2 2 u 106 256 277 1.250 6.193 0.150
    > *mauer.intranet. .DCFa. 1 u 253 256 377 0.154 0.068 0.071
    > -auth1.xs4all.nl 193.79.237.14 2 u 53 256 277 7.899 17.204 2.084
    > +ntp1.nl.uu.net .GPS. 1 u 8 256 337 13.599 6.001 8.832
    > -ntp3-rz.rrze.un .DCFp. 1 u 21 256 377 29.566 0.059 0.237
    > +ntps1-1.cs.tu-b .PPS. 1 u 1043 256 360 29.793 7.204 0.097
    > +chime1.surfnet. .GPS. 1 u 42 256 377 9.135 6.485 2.794
    > SHM(0) .SHM. 0 l 11 64 377 0.000 -5.365 1.810
    >
    > Why is the '.SHM.'-clock not even considered? Because of the negative offset?
    >
    >
    > Folkert van Heusden
    >


  5. Re: why is this clock not even considered?

    In article ,
    David L. Mills wrote:

    > documentation. The probable cause is dispersion too high or the noselect
    > option is present. The prefer option has nothing to do with this.


    I would have thought the most likely cause was dispersion too *small* not
    too large, causing the SHM time to fall outside the majority cluster.
    Clock drivers don't get a very large allowance for reading error, so,
    on a machine with the good precision, typical of modern machines, they
    need to be accurate to much better than the 5 to 10ms seen here.

    A contributory factor may be that the the same issue is causing the
    the reading error in the current selected system peer being underreported
    thus meaning that only times within a few hundred microseconds are
    acceptable. Many DCF clocks don't have that sort of reading accuracy.
    It's also not particularly difficult to exceed that sort of tolerance
    simply by the one way trip time from DCF to the receiver.

    I think that modern clock precisions really need the addition of an error
    tolerance parameter for clock drivers (which should be default to around
    800ms for the local clock driver!).

    In this case, given current configurability, one wants to trim out the
    systematic error in the SHM clock and also consider excluding the LAN
    based DCF source, if there is any doubt that its systematic error may not
    have been corrected.

  6. Re: why is this clock not even considered?

    David,

    The cause is not the intersection algorith, as to be considered and fail
    the intersection algorithm the tally code would be "x". According to the
    current algorithm, the cause would have to be rejection by the unfit()
    routine for the causes cited.

    With regard to your comments about the dispersion "too small", the
    allowance between zero-delay sources is by default 5 ms, not a few
    hundred microseconds. In any case, the tos mindisp command can be used
    to set the allowance to any value you need.

    Dave

    avid Woolley wrote:
    > In article ,
    > David L. Mills wrote:
    >
    >
    >>documentation. The probable cause is dispersion too high or the noselect
    >>option is present. The prefer option has nothing to do with this.

    >
    >
    > I would have thought the most likely cause was dispersion too *small* not
    > too large, causing the SHM time to fall outside the majority cluster.
    > Clock drivers don't get a very large allowance for reading error, so,
    > on a machine with the good precision, typical of modern machines, they
    > need to be accurate to much better than the 5 to 10ms seen here.
    >
    > A contributory factor may be that the the same issue is causing the
    > the reading error in the current selected system peer being underreported
    > thus meaning that only times within a few hundred microseconds are
    > acceptable. Many DCF clocks don't have that sort of reading accuracy.
    > It's also not particularly difficult to exceed that sort of tolerance
    > simply by the one way trip time from DCF to the receiver.
    >
    > I think that modern clock precisions really need the addition of an error
    > tolerance parameter for clock drivers (which should be default to around
    > 800ms for the local clock driver!).
    >
    > In this case, given current configurability, one wants to trim out the
    > systematic error in the SHM clock and also consider excluding the LAN
    > based DCF source, if there is any doubt that its systematic error may not
    > have been corrected.


+ Reply to Thread