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

91–100 of 128 posts

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

#91

Post by bawolff »

hansel_der wrote: post #86
bawolff wrote: post #68

Not trying to be dismissive but honest question: why would machine learning be good in this problem domain? Normally i think of machine learning as a good way to find patterns in high dimensional data, but clock skew doesn't seem like something that is high dimensional.

> why would machine learning be good in this problem domain? it doesn't have to be, market will decide.

I mean yes of course. The implicit underlying question i am asking is does their product make sense or is it a scam/snakeoil?

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

#92

Post by evol262 »

oefrha wrote: post #41
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…

[flagged]

Example of a garbage HN drive-by comment: this.

I've spent a _long time_ working in distributed systems with components which are "close to the metal". There are use cases for this, many of which are better solved by "hardware timestamping NICs" and "run a stratum 1/2 NTP server with high locality (and if you're geo-distributed, run multiple on systems dedicated to that purpose, because ensuring you're within nanoseconds of _someone else's_ infrastructure is generally an order or magnitude less important than internal coherence).

That was the best possible quote from the author/subject trying to explain the use cases. Did you even read TFA? It's completely unclear from their article what the intended uses cases are, what the problem space is, and how much working knowledge they have of existing solutions.

Naming people who invested in other companies who are investing in this one and showing what looks like a dashboard for a timekeeping solution is normal TechCrunch garbage, but that quote was a step above.

Comments like yours (going all the way back to /.) days really just tell me that you didn't read the article, and it makes it look like your primary goal is sophistry.

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

#93

Post by bitcharmer »

mlichvar wrote: post #73
bitcharmer wrote: post #62

Earlier quoted context omitted.

Could you provide examples of NIC models that can achieve that? So far I've only worked with gear that offers HW timestamps but that feature relies entirely on the availability of PTP signals in the first place.

Some models that are known to work well with chrony are Intel I210, I350, and X550. Those don't care about the protocol as they can provide hardware timestamps for all received packets. Other popular NICs like the Intel X540 or XXV/XL710 are limited to timestamping of PTP event messages in order to limit the rate of timestamps which needs to be handled by the driver. For those chrony supports an NTP-over-PTP protocol…

Thanks!

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

#94

Post by necovek »

paxys wrote: post #27
Uptrenda wrote: post #23

I was actually reading about this recently and learned about the time problem. Some interesting stuff I remember: * On LAN: NTP can get up to 1ms accuracy and on WAN about 10ms accuracy. * People's 'system clocks' use NTP for synchronization but can still be completely off. * When you call DataTime.now() in Javascript it returns the unix timestamp in UTC time. * Since it is UTC it will have the same value anywhere in…

One bit of clarification: > it returns the unix timestamp in UTC time Unix timestamp is ALWAYS the number of seconds since January 1st, 1970 00:00:00 UTC. It cannot be in any timezone.

I think stating it like that is a useful bit if redundancy: it's not overly long, and doesn't require the reader to know the exact definition.

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

#95

Post by unfocussed_mike »

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…

> it's hard to imagine who decided that "NTP, but machine learning" is a $21M idea

Bless you. Are you younger than 40? :-)

Tech people who are over about 40 have, alas, no trouble imagining this at all!

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

#96

Post by chrismorgan »

zokier wrote: post #75
Dylan16807 wrote: post #32

Earlier quoted context omitted.

"ALWAYS" is a bit much when we have leap seconds, though.

Specifically unix timestamp is number of days since 1970-01-01 × 86400 + seconds since midnight. The difference arises from the fact that in utc some days are 86401 seconds long, but unix timestamp just repeats the last second of the day instead of being simple ever increasing counter.

Most software does indeed ignore leap seconds, thereby generally matching UTC for times, but being discontinuous at leap second boundaries, and not matching UTC for durations. Sometimes this matching of POSIX behaviour is spelled out, but mostly it’s not.

As an example, since an ancestor comment was talking about JavaScript:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... says Date.now() “returns the number of milliseconds elapsed since January 1, 1970 00:00:00 UTC”, which wording would suggest the inclusion of leap seconds (since they have certainly elapsed).

However, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... mentions that Date.now(), Date.parse() and Date.UTC() ignore leap seconds; what it fails to mention is that actually it’s just that ECMAScript follows POSIX for time measurement throughout, though in a milliseconds base rather than seconds, meaning that everything to do with Date ignores leap seconds. (Citation: ECMA-262 §21.4.1.1 https://262.ecma-international.org/12.0/#sec-time-values-and...>; warning, 6.7MB HTML document, slow to load.)

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

#97

Post by zeckalpha »

radicality wrote: post #22

I did read the article and do see the work FB open sourced linked (100 microsecond accuracy), but will link directly to the FB blog here for anyone interested: https://engineering.fb.com/2021/08/11/open-source/time-appli... I’m curious, who is even the target customer here? Places like FB and Google are working on the problems themselves. They talked about some “latency sensei” product or something but what is it gon…

My guess is they are aiming to exit with a cloud provider that isn’t doing this stuff themselves yet, or one that doesn’t want their competitors to acquire this team.

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

#98

Post by SAI_Peregrinus »

jazzyjackson wrote: post #77
_3u10 wrote: post #36

Earlier quoted context omitted.

If only these devices had a clock capable of measuring time to within 1 nanosecond. If one has such an accurate clock they might be able to accurately plot their position on earth to within 1 ft merely by checking the timed pulses of orbiting satellites.

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

And GPS-disciplined oven controlled crystal oscillators (OCXOs) provide some of the best frequency accuracy and stability around. They range from about a hundred dollars up through a few thousand, depending on phase noise.

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

#99

Post by krisoft »

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…

> 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 it is a good business to specialise on it. But saying that nobody excep for Google, CockroachDB or someone doing database things uses time is bulshit and can be called out for what it is.

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

#100

Post by gnufx »

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…

What are those applications? They've passed me by unless that's meant to cover large-scale physics measurements of some sort. I don't understand how it would even make sense in mainstream supercomputers. It should be good to synchronize OS scheduling in HPC nodes to minimize jitter in tightly-coupled applications, but that's not ns stuff and I haven't come across it actually being done (though Bull had some support as free software).

I don't see how something like Kerberos or TOTP, that fails without some sort of synchonization, can be defined as not "using time" in a real sense. (If cluster nodes were drifting by seconds, I'd be checking them, even if that was only going to affect something like make.)

Post reply on HN