Clock Skew Exists
jvns.ca
jvns.ca
Hello Julia, the kind of skew that is a problem for Redlock, or other algorithms that would rely on the same clock assumptions, is not when the computer "logical" clocks skew, for example by getting a wrong time from NTP. By using the monotonically increasing clock API we only need to care about failures that cause the clock to go faster / slower even if never modified. Also note that there is no issues with clocks of different processes to be at a totally different absolute times, as long as they continue to count the time approximately at the same speed. If you restrict the failures to this class of issues, then to see it in the practice becomes not impossible but extremely rare. Most real world systems out there using proven algorithms, have to do the same assumptions on the fact that the system works in a mostly expected way. For example disk corruptions or network packets corruptions can cause the same issues, even if they are rarely checksummed at application level, or checked with a checksum length that does not make collisions impossible in the long run. Btw kudos for trying to reason with your head instead of trusting other people's or my words.
Btw this problems could be mitigated by changing the majority. For instance in the case of a distributed lock, it's possible to acquire the lock in 50% + 2 instances in order to consider the lock valid, so that in one instance the clock can misbehave safely.
...as long as they continue to count the time
approximately at the same speed.
1) all abstraction necessarily adds a performance penalty.
2) Hypervisors or VMs have core affinity, but, often, multiple VMs and Hypervisors are pinned to the same core. Since one cpu cannot expose time to two different vm requests at precisely the same time, there is always some variance.
3) Process isolation is pretty good, but total performance isolation is not quite the same.
There are a TON of papers written about VM and hypervisor time management. It's all fascinating and hard.
Imagine you have a data pipeline that spans multiple hosts, and you want telemetry on when an entity passes through each step? Suddenly you have to start caring about clock alignment in an order of magnitude comparable with network transit/computation time (microseconds) and that level of skew happens VERY often. There are certainly ways around this in how you build your system, but it's something that _must_ be considered and I find often isn't.
/u/devnull42 is doing it right: https://news.ycombinator.com/item?id=11075883