Live data from Hacker News

Open-sourcing a more precise time appliance

engineering.fb.com

101–110 of 188 posts

Re: Open-sourcing a more precise time appliance

#101
post #53

Earlier quoted context omitted.

Curious, why did telephony require such accurate clocks?

Not in telecommunications, but I do know that there are synchronous comm networks that don’t require any kind of sentinel / delimiter because there is a guarantee that the voltage will agree. My signals background mostly comes out of music, so somebody else probably has a better answer. But any time you need to convert between digital and analog signals relatively seamlessly, ie, introducing minimal processing overhe…

It is one of those problems that is really easy to ignore, until you can't. I was using a cheapo 8051 based logic probe the other day and had a lot of fun dealing with not only jitter of two different oscillators (probe + device under test) - but differences in response time between probes (within the same sample period). If you ever find yourself wondering much influence your MCU's 4 clock cycle per instruction architecture has on the waveforms you're looking at... you're about to have a very bad time.

Re: Open-sourcing a more precise time appliance

#102
post #62

Earlier quoted context omitted.

I'm curious: what's the use case for microsecond-precise timekeeping?

To monitor a control loop that ran in I could have used an in-between time unit, like hundredths of a millisecond, but that would have created embarrassingly long variable names.

I was wondering this as well. FB tech articles never seem to start with a use-case, application or statement of problem.

Re: Open-sourcing a more precise time appliance

#103
post #62

Earlier quoted context omitted.

I'm curious: what's the use case for microsecond-precise timekeeping?

There are plenty of practical applications for it. Imagine super high speed, high precision robotics, maybe a synthetic fiber layup machine or an exotic milling machine, that moves at 10m/s. If you have 1us of precision and accuracy then you can send movement commands that are precise down to 10um.

I had the same question - there are obviously a lot of applications for this, but why would a company like FB need it?

Re: Open-sourcing a more precise time appliance

#104
post #14

Off topic: I'm reminded of a very small unit of time that was devised to be a least common multiple of various division of time like 24fps, 30fps, 44.1kHz, and a ton of others in video and audio. Does anyone remember what this unit was?

Do you mean the facebook/oculus flicks? Wonder why the repo is archived... https://github.com/facebookarchive/Flicks ninjaed :(

That's exactly it! Thank you.

I would imagine it's archived because there's nothing else to really be done. It's basically a blog post. The header can apparently be replaced with three lines.

Re: Open-sourcing a more precise time appliance

#105
post #13

Off topic: I'm reminded of a very small unit of time that was devised to be a least common multiple of various division of time like 24fps, 30fps, 44.1kHz, and a ton of others in video and audio. Does anyone remember what this unit was?

I think you might be referring to this https://en.wikipedia.org/wiki/Flick_(time)

That's it! Thank you very much.

I searched around on Wikipedia for it and couldn't find it. I might recommend some edits when I have the time.

Re: Open-sourcing a more precise time appliance

#106

Man, tough crowd here. And someone who's been following precise timekeeping tech for 25 years now.. this is really cool! I think it's great some smart engineers have built a new reasonably compact and low cost very precise bit of timekeeping hardware. Thank you for sharing it open source!

I am torn. I absolutely love the technical blog post and the effort that went into open sourcing everything needed to build these devices, but, you know, Facebook. Compliments and respect to the engineers involved for really well done engineering.

Objectively speaking, Facebook has done both great things (e.g. from an engineering/tech perspective) and evil things (we all know). It's good that we honor the good too when we are flaming them for the bad.

Re: Open-sourcing a more precise time appliance

#107
Facebook isn't a good fit for me, but their work on open hardware for data centers has occasionally looked appealing.

I figure units doing open hardware could be like when the old SNL sketch about AT&T -- having the slogan "We don't care. We don't have to. We're the phone company." -- was of the same company that hosted Bell Labs.

Re: Open-sourcing a more precise time appliance

#108
post #103

Earlier quoted context omitted.

There are plenty of practical applications for it. Imagine super high speed, high precision robotics, maybe a synthetic fiber layup machine or an exotic milling machine, that moves at 10m/s. If you have 1us of precision and accuracy then you can send movement commands that are precise down to 10um.

I had the same question - there are obviously a lot of applications for this, but why would a company like FB need it?

Distributed databases I assume

Re: Open-sourcing a more precise time appliance

#109
post #68

Earlier quoted context omitted.

I am torn. I absolutely love the technical blog post and the effort that went into open sourcing everything needed to build these devices, but, you know, Facebook. Compliments and respect to the engineers involved for really well done engineering.

They've built and earned their (negative) reputation. This is cool, but it's like Philip Morris Tobacco Company coming out with a useful home appliance. Uhh....thanks?

Even a clock that moves backwards is right four times a day :)

Re: Open-sourcing a more precise time appliance

#110
post #53

Earlier quoted context omitted.

Curious, why did telephony require such accurate clocks?

Seems to be part of SONET and CDMA 2000 standards to keep network elements synchronized: * https://www.gps.gov/cgsic/meetings/2012/weiss1.pdf Specifically frequency and phase sync requirements: * https://en.wikipedia.org/wiki/Synchronization_in_telecommuni...

CDMA needs precise sync for soft-handoff, but that's tangential to the rest. SONET explains it better, but even SONET is decades newer than the original requirements.

The T1 was introduced in 1962, having been developed in the 50s. T1 is self-clocking, in that the receiver recovers sync from the line (and there are mechanisms to guarantee enough ones-density to keep the clock recovery circuit working), so a point-to-point T1 circuit with analog on either end has no need for external timing -- one end can just free-run and the whole thing is fine.

But when you start connecting T1 (DS1)s together, moving DS0 signals between them ("time-slot interchange"), or bundling them into higher-rate signals (DS3/T3 and then up into SONET), it's utter chaos unless they're all synchronized.

There's considerable detail in the BSTJ archives, I could dig up some links later.

Post reply on HN