[withinboredom]

For me, I almost stopped reading at the assertion that clock drift doesn't matter. They clearly didn't think through the constant fight that would occur over who the leader actually was and just hand-wave it away as 'not an issue.' They need to remove time from their equation completely if they want clock drift to not matter.

[pluto_modadic]

part of me thinks that clock drift would be reliably biased toward a particular node, not leapfrogging between two nodes.

[sillysaurusx]

It’s deeper than that. See the paper on time in distributed systems by Lamport: https://lamport.azurewebsites.net/pubs/time-clocks.pdf

There’s a relativity-like issue where it’s impossible to have a globally consistent view of time.

See IR2 for how to synchronize physical time in a distributed system.

“(a) If Pg sends a message m at physical time t, then m contains a timestamp Tm= C/(t). (b) Upon receiving a message m at time t', process P/ sets C/(t') equal to maximum (Cj(t' - 0), Tm + /Zm).”

I think the formula is saying that the clocks will only ever increase (i.e. drift upwards). If so, then you could imagine two processes leapfrogging if one of them sends a message that bumps the other’s clock, then that one sends a message back that bumps the first.

But I’m curious how it behaves if one of the clocks is running faster, e.g. a satellite has a physically different sense of time than an observer on the ground.

Also note the paper claims you can’t get rid of clocks if you want to totally order the events.

[rhaen]

It's a truly fantastic paper, but like many things the idea that it's impossible to have a perfectly consistent global view of time doesn't mean it's not possible to have a near-perfect one. The blog mentioned AWS's Timesync which lets you be synchronized into the microseconds (https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-ti...), and Google's TrueTime is used to give ranges of times that you're guaranteed to be within (https://cloud.google.com/spanner/docs/true-time-external-con...).

[withinboredom]

It's near-perfect ... until it isn't and everything goes to shit in a cascading wtafc (what-the-actual-fuck-catastrophe).

1ms is an extremely long time in computer land where decisions are made in nanoseconds. There are 1000 nanoseconds per millisecond.

[monocasa]

1000000 nanoseconds per millisecond.

[shadow28]

Think you mean micro rather than milli

[withinboredom]

Yes thank you!

[withinboredom]

> Also note the paper claims you can’t get rid of clocks if you want to totally order the events.

The order of events isn't important here. We only care about the 'last event' which everyone can agree on; they just can't agree on when it happened.

In other words, they can all agree that there is a leader; we just don't know if that leader is still alive or not. The best thing to do is simply make the leader election deterministically random:

1. 'seed' the file with a 'no leader' file.

2. at randomly short intervals (max latency you want to deal with, so like once every few seconds or so), try to claim the file by using the hash of the current file as your etag. The winner is the leader.

3. Once there is a leader and you are the leader, every N seconds, update the file with a new number, using the hash of the current file as the etag.

4. If you are not the leader, every N*(random jitter)*C (where C>N*2, adjust for latency), attempt to take the file using the same method above. If you fail, retry again in N*(random jitter)*C.

5. If the leader is taken, you are not the leader until you've held leadership for at least N seconds.

This doesn't necessarily remove the clock. However, most -- if not all -- modern clocks will agree that the length of a second is within a few nanoseconds of any other clock, regardless of how accurate its total count of seconds is since the epoch. It also probably doesn't work, but it probably isn't that far away from one that does.