Lecture 005 - Clock

Clock Synchronization

The actual ordering matter, not the timestamp

Time Standards:

• Universal Time (UT1, Greenwich Mean Time): astronomical observations

• Temps Atomique International (TAI): radiation emitted by Cesium atom (diverged due to slowing earth rotation)

• Temps Universal Coordonne (UTC): TAI + leap seconds (currently 27 leap seconds)

  • broadcast from radio stations: 1 microsecond
  • land-based stations: 0.1-10 millisecond

Cause of Imperfection

• Skew: difference when time sync

• Clock drift rate: quartz clocks drift 1 sec in 7-11-12 days.

Synchronization Technique

Naive Synchronization:

• Sender sends time T (sending time) in a message

• Receiver sets clock to T + D/2 (assuming transmission delay is bounded by D)

• Synchronization error is at most D/2 (but D is not bounded itself)

Cristian's Time Sync:

1. client request time from server at time $T_0$
2. server received request, it reply back with time $t$
3. client receive result from server at time $T_1$
4. client set its clock to $t + \frac{T_1 - T_0}{2}$ where the round trip time is $RRT = T_1 - T_0$

The accuracy is $\pm (RTT/2-\min)$ (where $\min$ is an estimated minimum one way delay) because we can guarantee when the machine receive time from time server, the ground truth time is within range $[t+\min, t+RTT-\min]$. Suppose the minimum one way delay $\min$ happens when message send from client to server, then the real-time when client received request is $t + (RRT - \min) = t + (T_1 - T_0 - \min)$, but client's clock is set to $t + \frac{T_1 - T_0}{2}$. In this case, we overestimated the real-time by $\frac{T_1 - T_0}{2} - \min$. If the minimum one-way delay $\min$ happens when the server replies back to the client, the real-time when the client received the request is $t + \min$. We underestimated the real-time by $\frac{T_1 - T_0}{2} - \min$.

Cristian's Time Sync only works if RTT (Round trip time) is short, since we need to have a low $\min$ to bound the time. Centralized server might fail.

Berkeley Algorithm:

• master can sync with UTC server (assume no RTT), not necessary

• a group of servers are elected into 1 master and other slave servers.

• master send its current time master to all slaves.

• slaves respond with time differences dxs.

• master receive 2 things: time difference, and calculated roundtrip time RTT.

• master average (median) the time difference and add RTT/2, then broadcast the adjusted time to slaves.

Network Time Protocol (NTP): (using Cristian's one-way messages)

• hierarchy of time servers

  • Class 1: connected to atomic clocks (UTC source)
    • Udel Master Time Facility (MTF) with a bunch of receivers
  • Class 2: sync to class 1 and 2
  • Class 3: sync to any server

• All messages use UDP

• Each message is with

  • Local times of Send and Receive of previous message
  • Local times of Send of current message

Logical Clocks

We don't care about actual time, we just need to know the event order. (Well, in fact, we don't have time, we have space-time)

Lamport Clocks

Lamport Clock: using event order to sync clocks

• observations

  • every send and receive events is a timestamp
  • every receive must happen after send
  • every event in the same process (machine) has ordered timestamp

• protocol

  • every process track a logical time represented by integer
  • every process, before send and receive event, increment timestamp
  • when a process send message, it send time (after increment)
  • when a process receive message, it update time (after increment) by maximum

Event e happens before e' implies timestamp at event e is smaller than timestamp at event e' $<span class="arithmatex"><span class="MathJax_Preview">(e \to e') \implies L(e) &lt; L(e')</span><script type="math/tex">(e \to e') \implies L(e) < L(e')$ The converse is not true. $<span class="arithmatex"><span class="MathJax_Preview">L(e) &lt; L(e') \;\not\!\!\!\implies (e \to e')</span><script type="math/tex">L(e) < L(e') \;\not\!\!\!\implies (e \to e')$ Therefore, Lamport Clocks does not capture causality

We can break ties using process ID to give us a total order: $L(e) = M * L_i(e) + i$

Vector Clocks

Vector clock provides a total order, as contrast to Lamport Clock's partial order.

Vector Clocks:

• each process initialize a vector who's length is the number of total processes $n$ in the system (initialize to all zero)

• process $i$ only manage element $i$ in vector (similar to lamport clock)

Recent Studies

Time Synchronization is still active research field.

Hardware Support: [DTP, SIGCOMM 2016]

• hop-hop synchronization

• 25.6 nanosecond accuracy (single hop)

Mostly Software: [HUYGENS, NSDI 2018]

• NIC timestamp support

• ML-based software filter

• 100 nanosecond accuracy

Summary

Clock Synchronization

• rely on timestamp network messages

• estimated delay for message transimission

• can synchronize to UTC or local server source

• clocks can never by exactly synchronized

• not good for distributed system

Logical Clocks:

• encode causality relationship

• Lamport Clock: one-way encdoing

• Vector Clocks: exact causality information