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