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

Clock synchronization is a nightmare

arpitbhayani.me

Post reply on HN
Print view View original

121–130 of 165 posts

Re: Clock synchronization is a nightmare

#121

Post by vel0city »

toast0 wrote: post #114
vel0city wrote: post #103

Earlier quoted context omitted.

Don't a lot of cellular networks rely on highly synchronized clocks to properly handle TDMA-style transmissions? Shouldn't they be very in sync with the towers' times?

I do believe there are (fairly) tight tolerances for clock synchronization between the network and the user equipment/handsets, but I don't know that it necessarily involves communicating the wallclock time. And the oscillators for signal timing aren't necessarily used for timekeeping.

I get that, but often the towers use GPS disciplined oscillators from what I understand (and have seen in limited circumstances), they inherently know exactly what time it is. Seems trivial to sync that as well, just kind of assumed they did that.

Re: Clock synchronization is a nightmare

#122

Post by toast0 »

christina97 wrote: post #115
toast0 wrote: post #98

Earlier quoted context omitted.

It's hard to keep a phone's clock closely synchronized because they experience a lot of temperature swings, going between pockets and hands and open air and sometimes in direct sun, and the processor goes between idle and 100% as well. Once you get to internationa phones, you'll have places where the phone does not include all timezones and specifically is missing the actual local timezone, so automatic sync is typic…

It’s not that hard. You would not expect 5 sec drift on phones that can sync time on the web at least once a day or once a week. A basic quartz crystal can keep time to within seconds per month of drift. High quality phones can do the same or better. Also the phone should keep track of system time as epoch time, and convert to local.

> Also the phone should keep track of system time as epoch time, and convert to local.

Yes, but imagine your local time is US Pacific time, but you have a phone intended to be sold in Mexico, so your phone only has Mexico time zones and MX Pacific Time has no DST. During part of the year, you can use automatic time sync, but during the summer, you disable automatic sync and set the clock so that the time displayed matches local time. Your epoch time is now an hour ahead of properly synched devices, but whatevs, your phone shows the right time and that's what counts.

Re: Clock synchronization is a nightmare

#123

Post by simonebrunozzi »

Back when I was studying computer science, I was taking the OS exam and the part about Lamport timestamp [0] was optional, but I had studied it because I loved it. When I mentioned it to my professor, he was so happy to hear something new that day that he asked me to describe it in details. This was the year 2001.

Many years later, in 2020, I ended up living in San Francisco, and I had the fortune to meet Leslie Lamport after I sent him a cold email. Lovely and smart guy. This is the text of the first part of that email, just for your curiosity:

Hey Leslie!

You have accompanied me for more than 20 years. I first met your name when studying Lamport timestamps.

And then on, and on, and on, up to a few minutes ago, when I realized that you are also behind the paper and the title of "Byzantine Generals problem", renamed after the "Albanian" generals to the suggestion of Jack Goldberg. Who is he? [1]

[0]: https://en.wikipedia.org/wiki/Lamport_timestamp

[1]: Jack Goldberg (now retired) was a computer scientist and Lamport's manager at SRI.

Re: Clock synchronization is a nightmare

#124

Post by otterley »

ssl-3 wrote: post #95
raron wrote: post #70

Earlier quoted context omitted.

> clock sync for civilians has never been easier I don't think civilian clock synchronization was an issue since a long time ago. DCF77 and WWVB has been around for more than 50 years. You could use some cheap electronics and get well below millisecond accuracy. GPS has been fully operational for 30 years, but it needs more expensive device. I suspect you could even get below 1 sec accuracy using a watch with a hacki…

Both of the WWVB clocks I've owned have been very fickle about how they're placed because RF be that way sometimes, and Colorado isn't exactly nearby to my location in Ohio. The first manufactured GPS clock I owned (as in: switch it on and time is shown on a dedicated display) was in a 2007 Honda. But a firmware bug ruined that clock: https://didhondafixtheclocks.com/ And even after it began displaying the right time…

The WWVB clocks are around the AM band, which means they carry a great distance despite their lower transmission power, but only at nighttime. Ohio is nothing; the signal needs to make it to the southern reaches of Florida.

Re: Clock synchronization is a nightmare

#126

Post by otterley »

sreekanth850 wrote: post #110

In physics, time is local and relative, independent events don’t need a global ordering. Distributed databases shouldn’t require one either. The idea of a single global time comes from 1980s single-node database semantics, where serializability implied one universal execution order. When that model was lifted into distributed systems, researchers introduced global clocks and timestamp coordination to preserve those g…

You can’t be certain that any given mutating operation you perform now won’t be relied upon for some future operation, unless the two operations are performed in entirely different domains of data. Even “not touching (by which I assume you mean mutating) the same data” isn’t enough. If I update A in thread 0 from 1 to 2, then I update B in thread 1 to the value of A+1, then the value of B could end up being 2 or 3, depending on whether the update of A reached thread 1.

Re: Clock synchronization is a nightmare

#128

Post by sreekanth850 »

otterley wrote: post #126
sreekanth850 wrote: post #110

In physics, time is local and relative, independent events don’t need a global ordering. Distributed databases shouldn’t require one either. The idea of a single global time comes from 1980s single-node database semantics, where serializability implied one universal execution order. When that model was lifted into distributed systems, researchers introduced global clocks and timestamp coordination to preserve those g…

You can’t be certain that any given mutating operation you perform now won’t be relied upon for some future operation, unless the two operations are performed in entirely different domains of data. Even “not touching (by which I assume you mean mutating) the same data” isn’t enough. If I update A in thread 0 from 1 to 2, then I update B in thread 1 to the value of A+1, then the value of B could end up being 2 or 3, d…

In distributed systems, dependencies flow forward, not backward. Causal dependency only exists when an operation actually references earlier state. If B = A+1, then yes, B is causally dependent on A and they must share an order. But that dependency is created by the application logic, not assumed globally in advance.

We shouldn’t impose a universal timeline just because some future operation might depend on some past one. Dependencies should be explicit and local: if two operations interact, they share a causal scope; if they don’t, they shouldn’t pay the cost of coordination.

Re: Clock synchronization is a nightmare

#129

Post by hnfong »

josephg wrote: post #53

> When two transactions happen at nearly the same time on different nodes, the database must determine which happened first. If clocks are out of sync, the database might order them incorrectly, violating consistency guarantees. This is only true if you use wall clock time as part of your database’s consistency algorithm. Generally I think this is a huge mistake. It’s almost always much easier to swap to a logical cl…

I wouldn't say it's a mistake. Distributed algorithms that depend on wall clock time generally give better guarantees. Usually you want these guarantees. The downside is of course you need to keep accurate time. In the cases you don't need them (eg. for the case you described), sure, but as an engineer you don't always get to choose your constraints.

Re: Clock synchronization is a nightmare

#130

Post by Fizzadar »

georgelyon wrote: post #12

Unfortunate that the author doesn’t bring up FoundationDB version stamps, which to me feel like the right solution to the problem. Essentially, you can write a value you can’t read until after the transaction is committed and the synchronization infrastructure guarantees that value ends up being monotonically increasing per transaction. They use similar “write only” operations for atomic operations like increment.

The key here is a singleton sequencer component that stamps the new versions. There was a great article shared here on similar techniques used in trading order books (https://news.ycombinator.com/item?id=46192181).

Agree this is the best solution, I’d rather have a tiny failover period than risk serialization issues. Working with FDB has been such a joy because it’s serializable it takes away an entire class of error to consider, leading to simpler implementation.

Post reply on HN