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
> styles.
> 
> 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
threw out.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160723/e7e684eb/attachment.bin>


More information about the devel mailing list