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

51–60 of 128 posts

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

#51

Post by TheDong »

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…

> With performance.now() -- its not a clock but a counter and browsers can intentionally limit its accuracy to make 'fingerprinting' harder.

The primary reason that performance.now()'s precision is limited is for security reasons.

Spectre showed that it was possible to perform timing attacks to leak other memory on the system, and having a browser leak memory from other processes is quite a dangerous attack. As part of spectre's mitigations, browsers began limiting performance.now()'s precision.

See docs on this: https://developer.mozilla.org/en-US/docs/Web/API/Performance...

Chromium's impl: https://chromium-review.googlesource.com/c/chromium/src/+/85...

Total aside, but it's also more accurate to say that performance.now() is a monotonic clock rather than a counter. Counters don't necessarily have relationships with elapsed time, but performance.now() does, and it's conceptually the same as 'CLOCK_MONOTONIC'.

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

#53

Post by wmf »

dchichkov wrote: post #24

Why not just synchronize to GPS time? It is pretty straightforward to get hardware timestamp on the 1PPS from the GPS. And then your time is as precise as the GPS clock, which can have a rubidium standard.

Then you need a GPS receiver in each server and a bunch of amps and cables to distribute the signal to every receiver.

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

#55

Post by maronato »

Dylan16807 wrote: post #25
dharmab wrote: post #21

Earlier quoted context omitted.

If the clocks are programmed to know their distances from each other, you can account for that.

You can, but is there any practical effect?

Imagine that the same message reaches more than one servers. Which one should record it? If they all are in sync you just use the one that received the event at the lowest timestamp

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

#56

Post by Nextgrid »

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]

Given how much complete garbage has been VC-funded (or rather, overfunded, since the correct amount of funding should've been $0) it's good to remain skeptical.

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

#57

Post by Nextgrid »

zbrozek wrote: post #30
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.

In a simple 100 mbps network where I needed good synchronization, I used the RXC pin of the MII bus as input to a PLL+VCXO and explicitly configured the PHYs in the link to be master-->slave in the desired clock distribution direction. PTP provided phase. Across a small network (a couple switch layers) I was seeing about ~20 ns of time uncertainty. Clocks were locked within about 2 ppb. Worked well enough for my need…

Out of curiosity, do you have any write-up or some documentation about this? Can't imagine a scenario where I'd need this any time soon but it sounds very interesting.

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

#58

Post by jakegold »

wmf wrote: post #54
aejnsn wrote: post #35

How has Chrony not been mentioned here? https://chrony.tuxfamily.org/

Chrony is still NTP. Clockwork is aiming to be far more precise.

It's hard to get much more accurate than Chrony with NTP. Even real-world PTP implementations don't often aim for more accuracy than is possible with Chrony.

Because it turns out NTP can be much more accurate than most people realize.

From the Chrony FAQ[1]:

> When combined with local hardware timestamping, good network switches, and even shorter polling intervals, a sub-microsecond accuracy and stability of a few tens of nanoseconds might be possible

Good network switches and NICs with hardware timestamping support are commonplace now in server environments. NTP with Chrony is pretty hard to beat in terms of simplicity, reliability, and accuracy.

1. https://chrony.tuxfamily.org/faq.html

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

#59

Post by Dylan16807 »

maronato wrote: post #55
Dylan16807 wrote: post #25

Earlier quoted context omitted.

You can, but is there any practical effect?

Imagine that the same message reaches more than one servers. Which one should record it? If they all are in sync you just use the one that received the event at the lowest timestamp

Now imagine the same scenario but one of the servers is eight feet to the left.

Does it matter that a different server picked up the message first?

Now what if the server just thinks it's eight feet to the left because the clock is out by several nanoseconds?

Can't you just ignore that, and still use the server that got the lowest timestamp?

What's the practical difference?

When the servers can communicate in x amount of time, the question was specifically about clock drift "much smaller than" x.

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

#60

Post by oefrha »

Nextgrid wrote: post #56
oefrha wrote: post #41

Earlier quoted context omitted.

[flagged]

Given how much complete garbage has been VC-funded (or rather, overfunded, since the correct amount of funding should've been $0) it's good to remain skeptical.

If your way of remaining skeptical is opening the HN discussion and jumping into the first crappy hot take concluding that all people involved are clueless idiots without even skimming the article, your skepticism doesn’t mean much.
Post reply on HN