Removing the worst cruft
Eric S. Raymond
esr at thyrsus.com
Sun Jul 24 03:10:45 UTC 2016
Gary E. Miller <gem at rellim.com>:
> Mark Atwood <fallenpegasus at gmail.com> wrote:
> > Re IRIG being "primary time source in high end audio and video work"
> > You are kidding me. SIgh.
> Sadly, not.
> > Can you expand on that for me please?
> My son does a lot of robotics, and some of the robots he works on
> are now doing high end work holding high speed cameras filming TV
> commercials and movies. NDA prevents me from saying the clients and
> technically I should not even know. But you would know some of them
> very well.
> Prolly by Xmas time you will be seeing some amazing new photography
> The audio, video and robotic equipment is all syncronized to IRIG
> time. This becomes very important when you get up to 1,000 frame
> a second stuff.
> I was also very surprised that IRIG was alive and well in this niche.
> I propsoed to them using NTP to sync the robots to the IRIG signal, but
> for now they are slaving the robot on an IRIG time sync box, and running
> everything else synce on IRIG.
And that's exactly what they *should* be doing.
This isn't an NTP use case, it's more like a PTP one - local sync with
higher precision requirements than you can get out of NTP. Whether they're
tracking UTC to within a specified number of microseconds isn't a
big deal, the big deal they have to be tracking *each other*.
I wouldn't use NTP for this if I could. They don't want to best-fit
to multiple clocks, they want to nail sync to a single master clock.
And, asnyway, I don't think you're describing a requirement for NTP to
*take in* IRIG as a primary clock source, either. Why do that? If the
IRIG sync box has any kind of digital output, even something as simple
as a one-wire 1PPS export, you run any NTP you want to be downstream of
the master sync clock from that rather than the IRIG.
I don't see any problem here that is best solved by the IRIG driver I just
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the devel