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

sheikdawoodrajali at gmail.com sheikdawoodrajali at gmail.com
Thu Apr 9 19:53:35 UTC 2009


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 127.0.0.0 mask 255.0.0.0
> >>> # Allow communication over primary
> >>> restrict <primary IP> mask 255.240.0.0 nomodify notrap
> >>> # Allow communication over secondary
> >>> restrict <secondary IP> mask 255.240.0.0 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




More information about the questions mailing list