[ntp:questions] local refclock and orphan mode...
joegwinn at comcast.net
Wed Nov 23 23:36:34 UTC 2011
In article <E1RTLiS-0007AX-89 at stenn.ntp.org>,
Harlan Stenn <stenn at ntp.org> wrote:
> Joe wrote:
> > Harlan wrote:
> > > If such networks have what they think is a valid use case for
> > > simultaneous use of both local refclocks and orphan mode, it would be
> > > Good to hear what that case is.
> > I may not be understanding the question correctly, but one
> > similar-sounding real-world application comes to mind:
> > There is a planned radar system where a GPS receiver distributes GPS
> > System Time via IRIG-B. There are a number of Intel x86-64 servers
> > running RHEL (with MRG) supporting realtime applications software. It
> > is necessary that this applications code be synchronized to GPS System
> > Time, so applications can stay in synch with the radar hardware command
> > pipeline.
> > One way to achieve this is to provide an IRIG receiver card, the Linux
> > I/O driver needed to access the IRIG card, and a compatible reference
> > clock driver compiled into the NTPv4 daemon. (Symmetricom offers such a
> > triplet; there may be others as well.) This allows application code to
> > use ordinary kernel-provided timers to trigger software to "make the
> > donuts" exactly when needed.
> > An alternative approach, successfully used on prior radars, is to have
> > the IRIG card (or custom equivalent hardware) generate hardware timing
> > interrupts, which interrupts are turned into UNIX signals sent to the
> > application code.
> If there are multiple machines with these refclocks then just "mesh"
> them together, and in this case I don't see why either orphan mode or
> the local refclock is needed.
There are two machines with IRIG connections and refclock drivers et al,
and a factor more servers with only NTP exchange via ethernet.
By "mesh them together", what do you mean?
> If I'm missing something, I can see that in the "old days" a local
> refclock would have been good to keep the machines sync'd together, and
> now orphan mode would do the same thing.
> I do not see that in this case that *both* the local refclock driver
> *and* orphan mode would be useful.
That was my suspicion, but of course this entire network is isolated
from the outside world, with only GPS to keep time by. Maybe I'm
unclear on the precise definition of "orphan mode?.
More information about the questions