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

Richard B. Gilbert rgilbert88 at comcast.net
Thu Apr 9 22:01:53 UTC 2009

sheikdawoodrajali at gmail.com wrote:
> On Apr 8, 12:34 am, David Woolley
> <da... at ex.djwhome.demon.co.uk.invalid> wrote:
>> sheikdawoodraj... at gmail.com wrote:
>>> On Apr 6, 7:05 pm, Steve Kostecke <koste... at ntp.org> wrote:
>>>> On 2009-04-06, sheikdawoodraj... at gmail.com <sheikdawoodraj... at gmail.com> wrote:
>>>> [snip: a 27 line block of text]
>>>>> Yes, that's what I'm experimenting now.
>>>> What are you experimenting with?
>>>>> I beleive theOrphanBroadcast Mesh will work when none of the
>>>>> systems configured with external time servers at all.
>>>> Why don't you test it? I have.
>>>>> I saw it working time-sync'ed after adding shim value "tos mindist
>>>>> 0.010" for correctness interval.
>>>> I've conducted extensive testing withOrphanModeand never had to add
>>>> a tos mindist command.
>>>>> I beleive the "time island" concept will work fine
>>>> The nodes will all be chasing whichever clock is chosen as the master.
>>>>> and time-sync will happen regardless of ANY time set in ALL the nodes
>>>>> running NTP service.
>>>> Why would you be changing the clock on systems which are running ntpd?
>>>>> Is there any restrictions in time difference on a time island (30
>>>>> minutes or less)??
>>>> Restrictions in the time island between what things?
>>>>> Here is the "ntp.conf" file on ALL the systems (7 nos):
>>>>> ------------------------------------------------------------------
>>>>> driftfile "C:\Program Files\NTP\etc\ntpd.drift"
>>>>> keys "C:\Program Files\NTP\etc\ntpd.keys"
>>>>> trustedkey 1
>>>>> # Any clock offset will be accepted
>>>>> tinker panic 0
>>>>> #shim added to the correctness interval
>>>>> tos mindist 0.010
>>>>> # We participate as orphans to auto-find a Time Server
>>>>> tosorphan6
>>>>> # Default restrict all
>>>>> restrict default ignore
>>>>> # Allow local host for utilities like ntpq
>>>>> restrict mask
>>>>> # Allow communication over primary
>>>>> restrict <primary IP> mask nomodify notrap
>>>>> # Allow communication over secondary
>>>>> restrict <secondary IP> mask nomodify notrap
>>>>> broadcastclient
>>>>> broadcast xx.yy.255.255 key 1
>>>>> broadcast xx.zz.255.255 key 1
>>>> What is the purpose of broadcasting on two different addresses?
>>>> --
>>>> Steve Kostecke <koste... at ntp.org>
>>>> NTP Public Services Project -http://support.ntp.org/-Hide quoted text -
>>>> - Show quoted text -
>>> [Steve] Why would you be changing the clock on systems which are
>>> running ntpd?
>>> Our test plan is to verify if the time-sync happens fine after
>>> reducing (approx 30 minutes)
>>> on a system in a "orphan" group.
>> NTP is designed on the basis that time behaves like time, at least as
>> obtained from a crystal oscillator.  Time doesn't experience phase
>> discontinuities of 30 minutes, so, although ntpd should eventually cope
>> (at least non-orphanmode), you are operating outside the specification.
>> In the recommeded configuration, ntpd will abort if the majority of its
>> sources suddenly change by that amount, although I've noticed you used
>> tinker (and hence taken ntpd out of any guaranteed configuration) to
>> override that.- Hide quoted text -
>> - Show quoted text -
> Steve,
> I am running the following case in "orphan mode" with SAME stratum.
> I need your advice if the test case scenario is valid?
> Operating System:
> Windows XP Embedded
> Package Version:
> NTP v4.2.4.p5
> Test Environment:
> 6 nodes connected in a network.
> There are NO external servers connected to a group of systems in a
> network on different subnets.
> Test Case:
> 1) Install NTP on ALL 6 nodes
> 2) ALL of the nodes with ntp.conf file identically configured as both
> broadcastclient and broadcast mode
>     with orphan mesh. There are NO external servers configured.
>      ...
>     tinker panic 0
>     tos orphan 6
>     broadcastclient
>     broadcast <primary address>
>     broadcast <secondary address>
>     ...
> 3) Stop ntp service on ALL the nodes
> 4) tweak the time on ALL the nodes.
> i.e
> 1st machine with <systemtime>
> 2nd machine with <systemtime + 10 minutes>
> 3rd machine with <systemtime + 20 minutes>
> 4th machine with <systemtime + 30 minutes>
> 5th machine with <systemtime + 15 minutes>
> 6th machine with <systemtime + 5 minutes>
> 5) start NTP service on ALL nodes and observe NTP status
> Expected Result:
> 1) Can I expect ALL the systems to be in SAME time after
> a period (may be after few hours) of time ?
> Thanks,
> Dawood

I wouldn't count on it!  The maximum slew rate is 500 PPM which, if 
memory serves me, translates to something like 43 seconds per day.

I'd guess it might take as long as a week to get all these machines to 
agree on a common time.

Is there some point to this exercise?

If you want the machines to agree, set all the clocks to the correct 
time before starting ntpd.  Even orphan mode should keep them more or 
less in agreement.

In a case like this, rdate(), if available would probably do just as well.

More information about the questions mailing list