In article <[email protected]>, Harlan Stenn <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
