[ntp:questions] local refclock and orphan mode...

Harlan Stenn stenn at ntp.org
Wed Nov 23 22:54:56 UTC 2011

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.

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.


More information about the questions mailing list