Q1Distributed System

In a single motherboard, billions of transistors are perfectly synchronized by a single, pulsing quartz oscillator. In a massive Distributed System spanning multiple continents, every single physical server possesses its own isolated quartz clock. Due to microscopic variations in temperature, battery voltage, and manufacturing defects, these hardware clocks mathematically drift apart by several milliseconds every day. In a system executing millions of transactions per second, a 5-second drift between Database Node A and Node B will catastrophically corrupt time-stamped data, overwrite newer files with older ones, and destroy the mathematical causality of the entire network. Clock Synchronization is the aggressive architectural discipline of forcing these disparate clocks into rigid alignment.

Cristian's algorithm is utilized when a distributed network has access to an absolute, highly accurate Time Server (e.g., a server physically wired to a GPS atomic clock receiver or a WWV radio antenna).

The Mathematical Execution

• 1. The Request: A client node realizes its clock might be drifting. It records its exact local time ($T_0$) and blasts a request packet to the Time Server over the network.
• 2. The Server Response: The Time Server processes the request, embeds its absolutely perfect, current atomic time ($T_{server}$) into a reply packet, and blasts it back to the client.
• 3. The Receipt: The client physically receives the packet and records its exact local arrival time ($T_1$).
• 4. The Catastrophic Network Latency: The client cannot simply set its clock to $T_{server}$. By the time the packet traversed the chaotic internet routers, $T_{server}$ is already in the past. The client must mathematically calculate the exact network transit time.
• 5. The Calculation: The client assumes the network latency is symmetrical. The total Round Trip Time (RTT) is $(T_1-T_0)$. The one-way transit time is exactly $RTT/2$.
• 6. The Correction: The client violently updates its local clock to: $$\text{New Time}=T_{server}+\frac{T_1-T_0}{2}$$

Cristian's algorithm fails catastrophically if the network latency is highly asymmetrical (e.g., the request takes 10ms, but the reply takes 500ms due to router congestion), resulting in massive mathematical inaccuracies.

Developed at UC Berkeley, this architecture is used when the system has absolutely zero access to a perfect external atomic clock. The goal is not to have the "real" time, but to violently force all nodes to agree on the exact same time, regardless of whether it is globally accurate.

The Master-Slave Daemon Architecture

• 1. The Time Daemon: One specific server is mathematically elected as the Master Time Daemon.
• 2. Aggressive Polling: Instead of waiting for clients, the Master proactively and aggressively blasts a time request to EVERY single node in the cluster simultaneously.
• 3. The Delta Collection: Every node replies with their current physical clock time. The Master mathematically calculates the exact time difference (Delta) between its own clock and every slave's clock, carefully factoring in network RTT.
• 4. The Fault-Tolerant Average: The Master executes a fault-tolerant averaging algorithm. It mathematically averages all the clock values, but it violently discards extreme outliers (e.g., a node whose clock is off by 3 hours, indicating a hardware failure).
• 5. The Command: The Master does NOT send the new calculated average time back (which would suffer latency again). Instead, it sends a highly specific mathematical command: "Node A, advance your clock by +12ms. Node B, slow your clock by -5ms." (Note: Clocks are never violently reversed backwards, as this corrupts compiling software; they are "slowed down" until they align).