Unreliable Clocks and Synchronization Issues

Key Insight

Computers employ two types of clocks: time-of-day clocks (wall-clock time, synchronized via NTP) and monotonic clocks (for measuring durations, guaranteed to always move forward). Time-of-day clocks are prone to various issues, including drift (e.g., 200 ppm for Google servers, resulting in 17 seconds drift per day without resynchronization), forced resets that can make time jump backward, misconfigured NTP servers, leap seconds, and virtualization challenges. These make them unsuitable for accurate duration measurement or reliable event ordering across systems.

Monotonic clocks, while safe for measuring elapsed time on a single machine (e.g., for timeouts), have absolute values that are meaningless and cannot be compared between different computers. Although NTP can 'slew' the monotonic clock's frequency to correct for drift, it cannot cause it to jump. The accuracy of clock synchronization, even with NTP, is limited by network delay and hardware drift, meaning a clock reading should be viewed as a range within a confidence interval, not a precise point.

Relying on time-of-day timestamps for ordering events, such as in last-write-wins conflict resolution, is dangerous. Clock skew can lead to causality violations where a later event receives an earlier timestamp, causing data loss. For example, a write at 42.004s might be overwritten by a causally earlier write at 42.003s due to clock differences. Logical clocks are a safer alternative for ordering events, focusing on relative sequence rather than absolute time. Specialized systems like Spanner use TrueTime API's confidence intervals and introduce deliberate waits to ensure causality, achieving high synchronization accuracy (within 7 ms) with dedicated hardware like GPS receivers.