[ntp:questions] NTP - orphan mode with SAME stratum ("tos orphan 6") FAIL to sync.

David Mills mills at udel.edu
Fri Apr 3 19:42:01 UTC 2009


sheikdawoodrajali at gmail.com,

You might want to review the architecture briefing on the NTP Project 
Page. Note the definitions of correctness interval, intersection 
algorithm and majority subset. With only two sources there can be only 
one majorite subset and that must include both sources. If the 
correctness intervals do not overlap, neither source is believed and 
both are marked x. This is not an implmentation matter; it devolves from 
the theory and has confused many folks in the past.

In order to minimuze the grief this can cause if the sources are very 
precise and have very low synchronization distance, but doffer by more 
than a few ms, a shim can be added to the correctness interval using the 
tos mindist comand. The mindist defaults to .005 s by compromise, but 
you can set it higher to be more forgiving, say .05, should your sources 
be expected to differ by that much..

Dave

sheikdawoodrajali at gmail.com wrote:

>Thanks for the info.
>
>[Dave] Your broadcast clients have very large offsets beyond the
>panic threshold (1000 s).
>  
>
>>>I verified my configuration file and it has "tinker panic 0" command
>>>      
>>>
>present to accept ANY offset value by ntpd service. Let me know if
>you
>think otherwise
>
>[Dave] Easiest way to start is to disable one of the rails and let the
>munchkins synchronize, then bring up the second rail.
>  
>
>>>I'll do it and let you know.
>>>      
>>>
>
>And also I've seen a "low" offset numbers for both primary/secondary
>ONLY
>when I start the ntpd service ONE-BY-ONE.
>
>For example:
>having 7 nodes in the environment, if I stop ALL of them and
>start 2 nodes only, the offset values are low and it sync fine.
>
>By doing the same way, starting services one-by-one works fine too..
>
>It fails only IF ALL of the services started @ once...
>
>may be the offset values are higher bcoz of time overlap.
>
>QSTN
>1) I doubt there could be problem/failures in "Leader" selection
>algorithm
>implementation in "ORPHAN" mode. Thoughts??
>
>2) Running 7 nodes in "ORPHAN mode with same stratum", how to
>verify who is the leader?
>
>
>Pls share your thoughts.
>
>
>~ DWD
>
>On Apr 3, 8:14 am, mi... at udel.edu (David Mills) wrote:
>  
>
>>sheikdawoodraj... at gmail.com,
>>
>>The x's have nothing to do with broadcast or withorphanor with the
>>number of hosts, which is unlimited. It has to do with the intersection
>>algorithm. Your broadcast clients have very large offsets beyond the
>>panic threshold (1000 s). In addition, your prmary and secondary rails
>>should be within a few milliseconds of each other or the correctness
>>intervals might not overlap. See the docuementation for the tos mindist
>>command.
>>
>>Easiest way to start is to disable one of the rails and let the
>>munchkins synchronize, then bring up the second rail.
>>
>>Dave
>>
>>
>>
>>sheikdawoodraj... at gmail.com wrote:
>>    
>>
>>>I am testing "Time Island" in NTP on Windows platform.
>>>I built the binaries using source downloaded from meinberg site.
>>>      
>>>
>>>Binaries built successfully and I'm testing it now.
>>>      
>>>
>>>NTP on ALL the nodes (7 nodes) with SAME stratum "orphanstratum 6"
>>>identically configured
>>>both as broadcast client and broadcast server ("Time Island") works
>>>fine.
>>>      
>>>
>>>Problem:
>>>--------------
>>>When all the 7 nodes have the same config, using "orphanstratum 6"
>>>and using the primary/secondary network broadcast FAILED to time-sync.
>>>      
>>>
>>>Time sync was successful ONLY if i do testing <=5 nodes.
>>>      
>>>
>>>And the "Selection algorithm tuning parameters" has the belowvalues:
>>>#define     NTP_MINCLOCK    3       /* min survivors */
>>>#define     NTP_MAXCLOCK    10      /* max candidates */
>>>#define     NTP_MAXASSOC    50      /* max associations */
>>>      
>>>
>>>Does it mean we cant have mode than 5 nodes (every node has 2
>>>broadcast interfaces, one for primary and other for secondary)
>>>configured in the SAME stratum level ?

>>>      
>>>
>>>If I have more 7 nodes during the testing, the "ntpq -q" results
>>>"X" condition to ALL the nodes during the query.
>>>      
>>>
>>>What's the MAX number of nodes that can be used forORPHANmode
>>>testing?
>>>      
>>>
>>>Any suggestions on this regard are welcome!!
>>>      
>>>
>>>BILLBOARD results:
>>>------------------------------
>>>      
>>>
>>>ntpq>
>>>peers
>>>    remote           refid      st t when poll reach   delay
>>>offset  jitter
>>>==========================================================================­====
>>>39.95.255.255   .BCST.          16 u    -   64    0    0.000
>>>0.000   0.001
>>>39.111.255.255  .BCST.          16 u    -   64    0    0.000
>>>0.000   0.001
>>>x39.92.128.6     127.0.0.1        6 u   59   64  376    0.236
>>>-130361   1.410
>>>x39.108.128.6    127.0.0.1        6 u   53   64  376    0.174
>>>-130361   1.396
>>>x39.98.208.6     127.0.0.1        6 u   61   64  376    0.210
>>>-548318   2.975
>>>x39.82.208.6     127.0.0.1        6 u   60   64  376    0.218
>>>-548318   2.541
>>>x39.81.224.16    127.0.0.1        6 u   42   64  376    0.393
>>>-455581   1.901
>>>x39.97.224.16    127.0.0.1        6 u   48   64  377    0.390
>>>-455581   1.621
>>>x39.81.224.15    127.0.0.1        6 u   45   64  376    0.216
>>>-455603   0.695
>>>x39.97.224.15    127.0.0.1        6 u   36   64  376    0.502
>>>-455604   0.698
>>>x39.81.224.6     127.0.0.1        6 u   43   64  377    0.176
>>>1059871   0.968
>>>x39.97.224.6     127.0.0.1        6 u   45   64  376    0.245
>>>1059868   0.815
>>>x39.97.64.6      127.0.0.1        6 u   29   64  376    0.236
>>>42.836   3.811
>>>x39.81.64.6      127.0.0.1        6 u   24   64  377    0.194
>>>43.809   4.880
>>>ntpq>
>>>      
>>>
>>>ntpq>
>>>assoc
>>>      
>>>
>>>ind assID status  conf reach auth condition  last_event
>>>cnt
>>>===========================================================
>>> 1 37893  c000   yes   yes   bad
>>>reject
>>> 2 37894  c000   yes   yes   bad
>>>reject
>>> 3 37895  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 4 37896  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 5 37897  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 6 37898  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 7 37899  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 8 37900  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 9 37901  7114    no   yes   ok  falsetick   reachable
>>>1
>>>10 37902  7114    no   yes   ok  falsetick   reachable
>>>1
>>>11 37903  7114    no   yes   ok  falsetick   reachable
>>>1
>>>12 37904  7114    no   yes   ok  falsetick   reachable
>>>1
>>>13 37905  7114    no   yes   ok  falsetick   reachable
>>>1
>>>14 37906  7114    no   yes   ok  falsetick   reachable
>>>1
>>>ntpq>
>>>      
>>>
>>>ntpq>
>>>passoc
>>>      
>>>
>>>ind assID status  conf reach auth condition  last_event
>>>cnt
>>>===========================================================
>>> 1 37893  c000   yes   yes   bad
>>>reject
>>> 2 37894  c000   yes   yes   bad
>>>reject
>>> 3 37895  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 4 37896  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 5 37897  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 6 37898  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 7 37899  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 8 37900  7114    no   yes   ok  falsetick   reachable
>>>1
>>> 9 37901  7114    no   yes   ok  falsetick   reachable
>>>1
>>>10 37902  7114    no   yes   ok  falsetick   reachable
>>>1
>>>11 37903  7114    no   yes   ok  falsetick   reachable
>>>1
>>>12 37904  7114    no   yes   ok  falsetick   reachable
>>>1
>>>13 37905  7114    no   yes   ok  falsetick   reachable
>>>1
>>>14 37906  7114    no   yes   ok  falsetick   reachable
>>>1
>>>ntpq>
>>>      
>>>
>>>ntpq>
>>>readvar
>>>assID=0 status=0011 leap_none, sync_unspec, 1 event,
>>>event_restart,
>>>version="ntpd 4.2.... at 1.1541-o Mar 15 23:23:09.92 (UTC-07:00) 2009
>>>(12)",
>>>processor="unknown", system="WINDOWS/NT", leap=00,
>>>stratum=6,
>>>precision=-20, rootdelay=0.000, rootdispersion=0.030,
>>>peer=0,
>>>refid=127.0.0.1, reftime=00000000.00000000  --- --- -- ----
>>>--:--:--,
>>>poll=6, clock=cd7b6f4c.4b49fb4e  Mon, Mar 30 2009 17:18:20.294,
>>>state=0,
>>>offset=0.000, frequency=0.000, jitter=0.001,
>>>noise=0.001,
>>>stability=0.000,
>>>tai=0
>>>ntpq>
>>>      
>>>
>>>ntpdc>
>>>listpeers
>>>broadcast
>>>39.95.255.255
>>>control
>>>39.81.64.6
>>>broadcast
>>>39.111.255.255
>>>control
>>>39.97.64.6
>>>control
>>>39.92.128.6
>>>control
>>>39.81.224.6
>>>control
>>>39.108.128.6
>>>control
>>>39.81.224.15
>>>control
>>>39.82.208.6
>>>control
>>>39.81.224.16
>>>control
>>>39.97.224.6
>>>control
>>>39.97.224.15
>>>control
>>>39.98.208.6
>>>control
>>>39.97.224.16
>>>ntpdc>
>>>      
>>>
>>>ntpdc>
>>>sysstats
>>>time since restart:
>>>2958
>>>time since reset:
>>>2958
>>>packets received:
>>>869
>>>packets processed:
>>>630
>>>current version:
>>>741
>>>previous version:
>>>0
>>>bad version:
>>>0
>>>access denied:
>>>92
>>>bad length or format:
>>>0
>>>bad authentication:
>>>0
>>>rate exceeded:
>>>0
>>>ntpdc>
>>>      
>>>
>>>ntpdc>
>>>sysinfo
>>>system peer:
>>>0.0.0.0
>>>system peer mode:
>>>unspec
>>>leap indicator:
>>>00
>>>stratum:
>>>6
>>>precision:
>>>-20
>>>root distance:        0.00000
>>>s
>>>root dispersion:      0.00002
>>>s
>>>reference ID:
>>>[127.0.0.1]
>>>reference time:       00000000.00000000  --- --- -- ----
>>>--:--:--
>>>system flags:         bclient auth monitor ntp kernel
>>>stats
>>>jitter:               0.000000
>>>s
>>>stability:            0.000
>>>ppm
>>>broadcastdelay:       0.003998
>>>s
>>>authdelay:            0.000006
>>>s
>>>ntpdc>
>>>      
>>>
>>>_______________________________________________
>>>questions mailing list
>>>questi... at lists.ntp.org
>>>https://lists.ntp.org/mailman/listinfo/questions- Hide quoted text -
>>>      
>>>
>>- Show quoted text -
>>    
>>
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>





More information about the questions mailing list