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

Joseph Gwinn joegwinn at comcast.net
Wed Nov 23 19:27:21 UTC 2011


In article <E1RT3Rk-0005Bs-Uk at stenn.ntp.org>,
 Harlan Stenn <stenn at ntp.org> wrote:

> Doug,
> 
> > On 11/21/2011 01:51 AM, Harlan Stenn wrote:
> > > I asked this on hackers@ and think a wider audience would be good.
> > > 
> > > In the old days, we had the local refclock. 
> > >  
> > > Now we have orphan mode. 
> > >  
> > > Can anybody think of a (good) use-case where one would want *both* the 
> > > local refclock *and* orphan mode configured for an instance of ntpd?
> > > 
> > 
> > Harlan,
> > 
> > I think you are confused about how things operate around here. The way
> > this works is that *we* ask you the questions and then *you* give us
> > answers;)
> 
> Mostly, that's true :)   Mostly...  In this case I'm trying to make sure
> we don't implement a change that would catch folks by surprise.
> 
> > The first thing that comes to mind is environments with mixed ntpd
> > versions. I realize that pre-4.2.2 was >5 years ago but sometimes change
> > management policies read more like change resistance policies.
> 
> Sure, but in the old days there was no orphan mode.  And there have been
> some other changes to things that would require updating ntp.conf files.
> 
> So while you mention good points, I'm still not hearing anybody say "We
> use local refclocks *and* orphan mode and the reason for that is X and
> here's how we expect it to behave." 
> 
> > What about the infamous interstellar/interplanetary ntp network?
> 
> If they are up for upgrading their ntpd instances, they can easily
> upgrade the config files at the same time.
> 
> 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.


Joe Gwinn



More information about the questions mailing list