Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clockwork raises $21M to keep server clocks in sync

techcrunch.com

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Clockwork raises $21M to keep server clocks in sync

#121

Post by nimish »

macroblocks wrote: post #5
nimish wrote: post #2

Interesting. CERN has white rabbit for sub-ns timing. Needs special hardware but is now IEEE 1588 (PTP) "High Accuracy" profile. I wonder how this deals with the numerous retimers and DSPs required for really high speed ethernet.

I’ve been working on fairly large scale broadcast television back-end systems which have been using 10/25/100G SMPTE 2110 IP for video flows instead of HD-SDI, and those have been timed with PTP for a while (SMPTE 2059-2 standard, which is a PTP profile). The GPS locked master clocks are custom hardware (ex: https://evertz.com/products/5700MSC-IP ), but a lot of the edge devices like the video playout servers are sta…

Regular PTP is old hat as you say. ~5ns though I thought needs some real thought, and picosecond sync needs a combo of PTP + SyncE + link compensation, which is now the "high accuracy" profile.

It's all fairly simple in the end if the hw has the tools but good luck buying SyncE or 1588 without $$$.

Re: Clockwork raises $21M to keep server clocks in sync

#122

Post by krisoft »

ctvo wrote: post #106
krisoft wrote: post #99

Earlier quoted context omitted.

> So yeah if you are letting your clocks drift by multiple seconds you aren't "using time" in any real sense. If you arrive to the railway station 10 minutes +-2 minutes before your train leaves you are using time. In a very real sense. In robotics we sync multiple computers on the robot to about miliseconds, that is using time. In a real sense. Maybe more accurate, cheaper sync will enable more applications. Maybe i…

> If you arrive to the railway station 10 minutes +-2 minutes before your train leaves you are using time. In a very real sense. In robotics we sync multiple computers on the robot to about miliseconds, that is using time. In a real sense. Why are you in a very specific technical discussion correcting what is obvious? Yes, you're using time. You're not using time at the precision this company is targeting. At that pr…

> You're offended you're not being included as users of time?

Please refrain from personal attacks. It is unecessary and doesn’t add to the conversation. Thank you.

> I use Google Maps all the time. I used it for my last trip! How dare you.

Do note that your example didn’t say “nobody uses maps”. If an imaginary salesperson would say “nobody uses maps” I would call bulshit on that too.

> Yes, you're using time.

Great, so the company representative should simply not say “nobody is using time”. And the commenter I was responding to shouldn’t say that applications which are fine with a lower accuracy “aren't ‘using time’ in any real sense”.

Heck, all I know maybe nanosecond accuracy is where the bees knee is, and everyone is going to be amazed by the awesome new applications it is going to enable. But you don’t need to disregard all the history of timekeeping and all the current applications to make that point.

On 28 April 1789 a mutiny broke out on HMS Bounty. The ship’s former captain, departing on a rowboat, demanded that the mutineers give him K2 the ship’s chronometer. The mutineers refused, because the chronometer was worth about as much as the whole ship, and they needed it for their onward navigation. Somebody should have told them that they are not using time in any real sense. Probably they would have laughed at that idea.

Re: Clockwork raises $21M to keep server clocks in sync

#123

Post by insaneirish »

galeaspablo wrote: post #78
insaneirish wrote: post #19

Earlier quoted context omitted.

> The figures (eg $21M) and names dropped (eg Stanford) are an appeal to authority, which does make me curious. They have the 'names' because they are a reputable group of people. They have been at this problem for a while, first with extensive research that required clock sync as a pre-requisite, and then to evolving into clock sync as a formidable problem unto itself. Clockwork is a rename of the company as far as…

Sure, but ‘names’ don’t explain how they do what they claim to do. Another reply kindly provided references to publications (which I couldn’t find myself) — they made for great reading. You seem to know their work, so if you have further publications, I’d love to get them please.

Here's a talk Balaji Prabhakar gave: https://www.youtube.com/watch?v=YQSA99nrFEU. Looks like the clock sync part starts about 30 minutes in.

Haven't watched this one, but might be complementary: https://www.youtube.com/watch?v=Opf9CBwP5R8.

Re: Clockwork raises $21M to keep server clocks in sync

#124

Post by [deleted] »

evol262 wrote: post #6

> “Currently, nobody uses time except for maybe Spanner at Google, CockroachDB or someone doing database things,” Rosenblum said. “We believe that there’s a lot more places, especially as more and more time-critical things came up. We can do time sync, since we figured out how to do that pretty well. And so we asked: is this part of a trend where we’re going to start programming these systems differently? And [resear…

[deleted]

Re: Clockwork raises $21M to keep server clocks in sync

#125

Post by jazzyjackson »

_3u10 wrote: post #116
jazzyjackson wrote: post #77

Earlier quoted context omitted.

I guess you're downvoted for being sarcastic or maybe people don't know 20 dollar GPS chips provide a ~10 nanosecond resolution clock

Haha I have no idea. But yeah just call the GPS algo a Time AI and voila, $21 m in funding to go get some kids in shenzen to put a GPS chip on a USB, PCIe, NVME slot. Hey look we got a GPU to learn the Kalman filter algo. Many are actually better than 10 ns basically a 1 foot CEP is 1 ns. If they are fixed and always on the accuracy it can build over a day is incredible.

granted it does need an unobstructed view of the sky, so getting it on a PCI-e board would be an innovation (:

Re: Clockwork raises $21M to keep server clocks in sync

#127

Post by hansvm »

pclmulqdq wrote: post #110
hansvm wrote: post #107

Earlier quoted context omitted.

The problem is that a pure software solution can't distinguish between clock skew and forward/backward relative time differences. Consequently, no such solution can guarantee error better than RTT/2. If your RTT is 2 microseconds, it's impossible to guarantee synchronization within hundreds of nanoseconds without incorporating additional information, regardless of jitter. Hence my initial question: are they adding ex…

You would enjoy reading the paper. They are making a few assumptions that turn out to be pretty good in a datacenter environment to simplify things. They are also using graph cycles to set clocks, which is a very different approach. My guess is that the precision of their approach comes at an accuracy cost, and the clocks are not particularly accurate.

You're right, I did enjoy reading the paper.

The graph cycles are neat, but they even admit in their own paper [0] that the approach is limited to half the max path asymmetry (RTT/2 if the asymmetry is totally unknown) -- pure software clocks have hard lower bounds on accuracy that can't be overcome without additional information (which digging elsewhere on their site it looks like they do actually integrate with sources like GPS antennas).

The rest of it is actually pretty interesting; in a datacenter context you might very well have low asymmetry, and everything else seems well done and likely to be much better than NTP for common scenarios.

[0] https://www.usenix.org/system/files/conference/nsdi18/nsdi18...

Re: Clockwork raises $21M to keep server clocks in sync

#128

Post by dchichkov »

dan-robertson wrote: post #88
KennyBlanken wrote: post #70

Earlier quoted context omitted.

1PPS signal distribution is not a complex or remotely difficult problem.

For some reason companies that care a lot about clock sync don’t seem to do this so perhaps there is some other reason.

A local GPS-disciplined NTP server, distributing time over 1GbE or 10GbE goes a long way. I can't think of any application, besides HFT and maybe some science experiments that need better precision.

And even in HFT, it is silly to try to use your x64 system time to get nanosecond precision. Even if you are really good, using bare hardware, all your code and data is in L2, an x64 system would still be giving you 100ns level jitter. No matter what you do. What you want is to have your network card (or FPGA) timestamping the packets accurately. And then releasing these packets at a precise timestamp.

Saying that, maybe Clockwork is doing something completely different. And not in nanosecond level, but at a millisecond level. They talk about "measure true one-way delays of a packet or remote procedure call, discover network bottlenecks and "hiccups" (outages lasting a few seconds), and identify underperforming VMs arising from "noisy neighbors." Now, that could indeed be useful.

Post reply on HN