Clock Synchronization Is a Nightmare

(arpitbhayani.me)

40 points | by grep_it 4 days ago

10 comments

  • hinkley 0 minutes ago
    [delayed]
  • georgelyon 31 minutes ago
    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.
  • kobieps 35 minutes ago
    Even just a single accurate clock is a nightmare... https://www.npr.org/2025/12/21/nx-s1-5651317/colorado-us-off...
  • hinkley 21 minutes ago
    Vector clocks are one of the other things Barbara Liskov is known for.
  • maximinus_thrax 36 minutes ago
    I wouldn't say it's a 'nightmare'. It's just more complicated than what regular folk think computers work when it comes to time sync. There's nothing nightmareish or scary about this, it's just using the best solution for your scenario, understanding limitations and adjusting expectations/requirements accordingly, perhaps relaxing consistency requirements.

    I worked on the NTP infra for a very large organization some time ago and the starriest thing I found was just how bad some of the clocks were on 'commodity hardware' but this just added a new parameter for triaging hardware for manufacturer replacement.

    This is an ok article but it's just so very superficial. It goes too wide for such a deep subject matter.

    • blibble 27 minutes ago
      PTP isn't even that much more difficult, as long as you planned for it form the start

      you buy the hardware, plug it all in, and it works

  • koudelka 1 hour ago
    the Huygens algorithm is also worth a look

    https://www.usenix.org/system/files/conference/nsdi18/nsdi18...

  • mgaunard 35 minutes ago
    Another protocol that's not mentioned is PPS and its variants, such as WhiteRabbit.

    A regular pulse is emitted from a specialized high-precision device, possibly over a specialized high-precision network.

    Enables picosecond accuracy (or at least sub-nano).

  • emptybits 1 hour ago
    Normally I would nod at the title. Having lived it.

    But I just watched/listened to a Richard Feynmann talk on the nature of time and clocks and the futility of "synchronizing" clocks. So I'm chuckling a bit. In the general sense, I mean. Yes yes, for practical purposes in the same reference frame on earth, it's difficult but there's hope. Now, in general ... synchronizing two clocks is ... meaningless?

    https://www.youtube.com/watch?v=zUHtlXA1f-w

    • hinkley 34 minutes ago
      Einstein was worried about whether people in two different relativistic frames would see cause and effect reversed.
      • emptybits 23 minutes ago
        Wild. My layperson mind goes to a simple example, which may or may not be possible, but please tell me if this is the gist:

        Alice and Bob, in different reference frames, both witness events C and D occurring. Alice says C happened before D. Bob says D happened before C. They're both correct. (And good luck synchronizing your watches, Alice and Bob!)

        • hinkley 14 minutes ago
          Yes that definitely happens. People orbiting Polaris would be seeing two supernovas explode at different times than us due to the speed of light. Polaris is 400 light years away so the gap could be large.

          But when you are moving you may see very closely spaced events in different order, because you’re moving toward Carol but at an angle to Doug. Versus someone else moving toward Doug at an angle to Carol.

        • mrkeen 16 minutes ago
          That will be the case when Alice stands close to where C happens, and Bob stands close to where D happens.

          It's a little trickier to imagine introducing cause-and-effect though. (Alice sees that C caused D to happen, Bob sees that D caused C to happen).

          I think a "light cone" is the thought-experiment to look up here.

          • hinkley 13 minutes ago
            If Bob and Alice are moving at half the speed of light in opposite directions.
    • m463 28 minutes ago
      it might be meaningless, but in practical terms just don't check util.c from the gravity well into the git repo in orbit.
  • yapyap 48 minutes ago
    Love learning new things. This also explains why my casio clock sync starts skewing over time
  • jeffbee 1 hour ago
    PTP requires support not only on your network, but also on your peripheral bus and inside your CPU. It can't achieve better-than-NTP results without disabling PCI power saving features and deep CPU sleep states.
    • pclmulqdq 1 hour ago
      You can if you just run PTP (almost) entirely on your NIC. The best PTP implementations take their packet timestamps at the MAC on the NIC and keep time based on that. Nothing about CPU processing is time-critical in that case.
    • rcxdude 1 hour ago
      How so? If the NIC is processing the timestamps as it arrives/leaves on the wire, the latency and jitter in the rest of the system shouldn't matter.