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

101–110 of 128 posts

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

#101

Post by uvdn7 »

I am skeptical to say the least.

TrueTime, PTP, FB’s time card, all solve one problem that is to provide a bound where “true time” falls in. You need to be able to _guarantee_ the precision. If you say the true time lies between [T - d, T + d], it must be the case. The spanner paper provides data that the probability of TrueTime being wrong is less likely than random hardware failures (bit flip, etc.). Nothing is 100% in computer, but once you have like 20 9’s of reliability, our society has collectively accepted it as good enough (like we assume hash collision would never happen).

Now AFAIK, no machine learning model can come even close to 10 9’s of accuracy. Clock, to me, is a piece of foundational infrastructure that should provide a very solid and simple mental model so we can reason about it and build other things on top. I am skeptical that NTP + ML would work.

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

#104

Post by ignoramous »

paxys wrote: post #9
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…

None of the services you mentioned need even close to nanosecond precision between servers to operate. Applications that do (other than the ones in the article like Spanner) are concentrated in supercomputing/scientific computing and spend a LOT of money on the problem. So yeah if you are letting your clocks drift by multiple seconds you aren't "using time" in any real sense. If these folks can achieve what they want…

Google uses precision time (SunDial) for observability, telemetry, congestion control too: https://www.youtube.com/watch?v=GEXP68yNPPM

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

#105

Post by WinterMount223 »

Dylan16807 wrote: post #26
WinterMount223 wrote: post #18

Earlier quoted context omitted.

For GPS precision is much more important than accuracy.

Precision vs. accuracy of what measurement? For GPS to work at all, you need very accurate knowledge of the offset between each satellite's signal. The only way I can think of to have precision but not accuracy is if you design a system where there's a buffer between the antenna and the signal processing and you don't know how long the buffer is. Is a design like that a practical concern?

Of UTC. Theoretically GPS can work out of sync with respect to UTC as long as all satellites are in sync among themselves.

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

#106

Post by ctvo »

krisoft wrote: post #99
paxys wrote: post #9

Earlier quoted context omitted.

None of the services you mentioned need even close to nanosecond precision between servers to operate. Applications that do (other than the ones in the article like Spanner) are concentrated in supercomputing/scientific computing and spend a LOT of money on the problem. So yeah if you are letting your clocks drift by multiple seconds you aren't "using time" in any real sense. If these folks can achieve what they want…

> 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 precision, there are few current use cases, but if they make it cheaper, there will be more. What's there to argue here? You're offended you're not being included as users of time?

"We're lunching more accurate satellite imaged maps. The current users are largely nation states and niche industries due to its cost. This will enable more map use cases"

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

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

#107

Post by hansvm »

pclmulqdq wrote: post #81
hansvm wrote: post #11

There are strong lower bounds in the error of pure-software time synchronization techniques. Is the proposal to incorporate additional hardware, or are they just probabilistically increasing the accuracy? If the latter, what applications can benefit from maybe being better synchronized, not being able to measure how much better the synchronization is, and maybe still having the same worst-case bounds that other algor…

The lower bounds are based on the use of occasional time measurements. In PTP terms, the clockwork algorithm involves using a high volume (~10k/second) of peer delay requests, and discarding almost all of them. Only the ones that are deemed to be "pure" are used to adjust clocks. By using a high volume of requests, they can actually average out a lot of the well-behaved jitter sources.

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 extra information to actually achieve those stated goals, or are there algorithms just "probably" better, and in the latter case what are the use cases? Distributed transactions and whatnot are fundamentally broken if your "better" synchronization might still be wrong.

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

#108

Post by hn_throwaway_99 »

dan-robertson wrote: post #83
hn_throwaway_99 wrote: post #3

Google Cloud Spanner uses atomic clocks to be able to synchronize using timestamps across distributed DBs. CockroachDB does not require atomic clocks, but I believe there is an "atomic clock mode" available. This approach sounds like it doesn't use atomic clocks, but instead just machine learning algorithms to detect offsets. Would like to understand if the founders consider their approach to be a viable alternative…

I thought even spanner only relied on sync in the 100us-1ms range. Maybe I’m out of date or it’s more about having clocks advancing at a very reliable rate? Usually ‘atomic clocks’ means ‘gps appliance gets time from atomic clocks in gps satellites’ but maybe not in this case.

> Usually ‘atomic clocks’ means ‘gps appliance gets time from atomic clocks in gps satellites’ but maybe not in this case.

No, Spanner has atomic clocks running in each data center.

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

#109

Post by karpierz »

Dylan16807 wrote: post #26
WinterMount223 wrote: post #18

Earlier quoted context omitted.

For GPS precision is much more important than accuracy.

Precision vs. accuracy of what measurement? For GPS to work at all, you need very accurate knowledge of the offset between each satellite's signal. The only way I can think of to have precision but not accuracy is if you design a system where there's a buffer between the antenna and the signal processing and you don't know how long the buffer is. Is a design like that a practical concern?

They're saying that as a receiver of GPS signals, it doesn't matter if your clock is out of sync with everyone else's clocks, as long as it measures the length of a nanosecond accurately.

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

#110

Post by pclmulqdq »

hansvm wrote: post #107
pclmulqdq wrote: post #81

Earlier quoted context omitted.

The lower bounds are based on the use of occasional time measurements. In PTP terms, the clockwork algorithm involves using a high volume (~10k/second) of peer delay requests, and discarding almost all of them. Only the ones that are deemed to be "pure" are used to adjust clocks. By using a high volume of requests, they can actually average out a lot of the well-behaved jitter sources.

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.
Post reply on HN