[ntp:questions] local refclock and orphan mode...
unruh at invalid.ca
Thu Nov 24 00:30:00 UTC 2011
On 2011-11-23, Joseph Gwinn <joegwinn at comcast.net> wrote:
> 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 those other machines are getting thier time from the IRIG equipped
machines, then they certainly need niether ophan or local modes. Thos
with the receivers also do not need it since they get their time from
the refclock driver. The only time when either local or orphan might be
useful is if for some reason the IRIG receivers all failed but you still
want to sync allo the clocks to the server.
>> 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?.
> Joe Gwinn
More information about the questions