# 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)

• land-based stations: 0.1-10 millisecond Distribution of Clock Drift in Practice: Geng, Yilong, et al. "Exploiting a natural network effect for scalable, fine-grained clock synchronization." NSDI, 2018.

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: in this example, (a, b, c, d, f) is transitive, but (e) is concurrent with (a, b, c, d)

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' $ The converse is not true. $ Therefore, Lamport Clocks does not capture causality Total order Lamport Clock: Original Lamport Clock Value * number of processes + current process id

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

Table of Content