Computer Engineering Department

Faculty of Engineering and Informatics

Universitas Multimedia Nusantara

CE739-Mobile Pervasive
Computing
Time & Synchronization
Dareen K. Halim
Hargyo Tri Nugroho
Samuel

ã 2012, I. Gupta, K. Nahrtstedt, S. Mitra,

N. Vaidya, M. T. Harandi, J. Hou
Target competencies
Code Description
SUB- Mahasiswa mampu menerapkan teknik-teknik sinkronisasi untuk
CPMK 6 mengatasi permasalahan waktu pada sistem terdistribusi – C3

2
Contents
• Introduction
• Why time synchronization
• System model for time synchronization
• Physical clock synchronization
• Cristian algorithm
• Berkeley algorithm
• Network Time Protocol (NTP)
• Logical clock synchronization
• Lamport timestamp
• Lamport vector timestamp

3
Introduction to time
synchronization

4
Why Synchronization
• You want to catch the 6.05 pm shuttle bus at one
shopping mall, but your watch is off by 15 minutes
• What if your watch is Late by 15 minutes?
• What if your watch is Fast by 15 minutes?

• Synchronization is required for

• Correctness
• Fairness
Why Synchronization
Cloud airline reservation system 4. OK, Flight GA-123
full
1. Reserve last seat at Local time
Flight GA-123 3. Flight GA-123 9h:10m:10.11s
Clie Server full
Server
nt A B
2. OK, reserved at
Local time 5. Flight GA-123
9h:15m:32.45s status?
CONFUSED

Server 6. May execute incorrect or

unfair actions.
C
System model – Processes and Events
• An Asynchronous Distributed System (DS) consists of a number of
processes.
• Each process has
• a state (values of variables).
• takes actions to change its state, which may be:
• an instruction or
• a communication action (send, receive).
• An event is the occurrence of an action.
System model – Processes and Events
• Each process has a local clock – events within a process can be
assigned timestamps, and thus ordered linearly.
• But – in a DS, we also need to know the time order of events
across different processes.
• Clocks across processes are not synchronized in an asynchronous DS
• unlike in a multiprocessor/parallel system
• Process clocks can be different
• Need algorithms for either (a) time synchronization, or (b) for
telling which event happened before which
Physical clock synchronization

9
Physical Clocks & Synchronization
• In a DS, each process has its own clock.
• Clock Skew versus Drift
• Clock Skew = Relative Difference in clock
values of two processes
• Clock Drift = Relative Difference in clock
frequencies (rates) of two processes
• A non-zero clock drift causes skew to increase
(eventually).
• Assume a Maximum Drift Rate (MDR) of a
clock
• Absolute MDR is defined relative to
Coordinated Universal Time (UTC)
• MDR of a process depends on the
environment.
• Max drift rate between two clocks with similar
MDR is 2 * MDR  Why? Consider the extreme
of one drifting right and another drifting left
Let’s do some math! 
• Max-Sync-Interval (when to sync) =
(MaxAcceptableSkew - CurrentSkew) /
(MDR * 2)
(i.e., distance/speed = time)
Think of it as “Ouch, we have x seconds before the
currentSkew reaches MaxAcceptableSkew”
Synchronizing Physical Clocks – “Accurate”
Ci(t): the reading of the software clock
at process i when the real time is t.

• External synchronization: For a • Internal synchronization: For a

synchronization bound D>0, and for synchronization bound D>0,
source S of UTC time,

for i, j=1,2,...,N and for all real

for i=1,2,...,N and for all real times
t.
times t.

Clocks Ci are externally accurate to Clocks Ci are internally accurate

within the bound D. within the bound D.
Some fun - Synchronization Example
• Form a group of 2
• Imagine the two of you having own local clock
• You want to do something on certain time e.g., saying HELLO,
exactly together
• How do you synchronize the action?
• Note: you can communicate, but without speaking
Clock Synchronization Using a Time
Server

mr

mt
p Time server,S
Cristian’s Algorithm
• Uses a time server to synchronize clocks
• Time server keeps the reference time (say UTC)
• A client asks the time server for time  the server responds
with its current time T  and the client uses this received value
to set its clock
• But network round-trip time introduces an error…
Cristian’s Algorithm
• Let RTT = response_received_time – request_sent_time (measurable at client)
• Also, suppose we know:
1. the minimum value min of the client-server one-way transmission time (Depends
on what?)
2. and that the server timestamped the message at the last possible instant before
sending it back (what if it does not?)
• Then, the actual time could be between [T + min, T + RTT - min]
T + min  server timestamp right before sending response to client
T + RTT - min  server timestamp right after the request arrived
Cristian’s Algorithm
• Client sets its clock to halfway between T+min and T+RTT - min i.e., at
(T+RTT)/2
 Expected (i.e., average) skew in client clock time should be significantly smaller than the
RTT
• Can increase clock value, but should never decrease it – Why?
• Future events may have smaller timestamp than previous events

• Can adjust speed of clock too (take multiple readings) – either up or down is ok.
• For unusually long RTTs, repeat the time request
• For non-uniform RTTs, use weighted average
avg-clock-errorn = (w * latest-clock-error) + (1 – w) * avg-clock-error n-1
Cristian’s Algorithm
 Works for smaller RTT
 Using single time server
 Abnormal time server is out of scope
Berkeley Algorithm
• Uses an elected master process to synchronize among clients, without
the presence of a time server
• The elected master regulates the time synchronization process
• 1 process, the master, polls others (slaves) by broadcast
• Slaves reply with their times
• Master estimates their local times using round-trip times (as above)
• Master averages all these (and its own time)  eliminating any times with excessive
RTT
• Also eliminates any wrong clocks
• Rather than send back correct time, master sends back to each slave its own delta
(+/-)
Berkeley Algorithm
(3:25 + 2:50 + 3:00)/3 = 3:05
Berkeley Algorithm
• Multiple leaders may also be used.

Averaging client’s clocks may cause the entire system to drift

away from UTC over time (this is an Internal Synchronization)

 Failure of the master requires some time for re-election, so

drift/skew bounds cannot be guaranteed
The Network Time Protocol (NTP)
• To provide a reliable service that can survive lengthy losses of
connectivity

• To enable clients to resynchronize sufficiently frequently to

offset the rates of drift found in most computers

• To provide protection against interference with the time

service, whether malicious or accidental
The Network Time Protocol (NTP)
• Uses a network of time servers to synchronize all processes on
a network.
• Time servers are connected by a synchronization subnet tree.
The root is in touch with UTC.
Primary server, direct synch.
1

Secondary servers,
synched by the 2 2 2
primary server Stratum 3,
synched by the
3 3 3 3 3 secondary
3
servers
Messages Exchanged between
NTP server and client
Each message bears
• timestamps of recent message events
• local time when the previous NTP message was sent and received
• local time when the current message was transmitted.

Server T1 T2
Time

m m'

Time
Client T0 T3
Start ‘End’
Quick glance on NTP synchronization
Client calculates these and adjust Server T1 T2
Time
locally
• The time offset between server and m m'
client
Time
Client T0 T3
• Round trip delay
T0 = client’s timestamp when sending m (request)
T1 = server’s timestamp when receiving m (request)
• These steps may be repeated, with value
T2 = server’s timestamp when sending m’ (reply)
and being statistically analyzed and
filtered T3 = client’s timestamp when receiving m’ (reply)
• Then the algorithm will determine which
peers to use and what value for
synchronization

24
Logical clock synchronization

25
Logical Clocks
• Is it always necessary to give absolute time to events?
• Suppose we can assign relative time to events, in a way that does not violate their
causality
• Well, that would work – we humans run our lives without looking at our watches for
everything we do
• First proposed by Leslie Lamport in the 70’s (Wow!)
• Define a logical relation Happens-Before () among events:
• On the same process: a  b, if time(a) < time(b)
• If p1 sends m to p2: send(m)  receive(m)
• (Transitivity) If a  b and b  c then a  c
Logical Clocks
• Lamport Algorithm assigns logical timestamps to events:
• All processes use a counter (clock) with initial value of zero
• A process increments its counter when:
• a send or an instruction happens at it.
• The counter is assigned to the event as its timestamp.
• A send(message) event carries its timestamp
• For a receive(message) event, the counter is updated by
max(local clock, message timestamp) + 1
Events Occurring at Three Processes
A process increments its counter when a send or an instruction happens at it

p1
a b m1

p2 Physical
c d time
m2

p3
e f
Lamport Timestamps
A process increments its counter when a send or an instruction happens at it

0 1 2
p1
a b m1

0 3 4
Physical
p2
time
c d m2

0 1 5
p3
e f
Find the Mistake: Lamport Logical Time
Physical Time

p 1 0 1 2 3 4
1 2 4
p 2 0 3
2
3
6
p 3 0 4
5 6
8
3
4
7
p 4 0 6 7
5

n
Clock Value
timestamp
Message
Corrected Example : Lamport Logical
Time
Physical Time

p 1 0 1 2 7 8
1 2 8
p 2 0 3
2
3
6
p 3 0 4
5 9
10
3
4
7
p 4 0 6 7
5

n
Clock Value Assume 3 and 7 are
timestamp logically concurrent
Message events
Vector Logical Clocks
• With Lamport Logical Timestamp 
• e  f  timestamp(e) < timestamp (f), but
• timestamp(e) < timestamp (f)  {e  f} OR {e and f concurrent}
• Vector Logical time addresses this issue:
• N processes. Each uses a vector of counters (logical clocks), initially all zero
• ith element is the clock value for process i
• Each process i increments the ith element of its vector upon an instruction or send
event.
• Vector value is timestamp of the event
• A send(message) event carries its vector timestamp (counter vector)
• For a receive(message) event, Vrecv[j] Max(Vrecv[j] , Vmsg[j]), if j is not self
Vrecv[j] + 1 otherwise
Vector Timestamps
(1,0,0) (2,0,0)
p1
a b m1

(2,1,0) (2,2,0)
Physical
p2
time
c d m2

(0,0,1) (2,2,2)
p3
e f
Example: Vector Timestamps
Physical Time

1,0,0,0 2,0,0,0 4,0,2,2

p 1 0,0,0,0 3,0,2,2
(1,0,0,0)
1,2,0,0 (4,0,2,2)
p 2 0,0,0,0
1,1,0,0 (2,0,0,0) (1,2,0,0)
(2,0,2,2)
2,0,2,0
p 3 0,0,0,0
2,0,1,0 2,2,3,0 4,2,4,2 4,2,5,3
(2,0,2,0) (2,0,2,3)
p 4 0,0,0,0 2,0,2,2
2,0,2,3
2,0,2,1

n,m,p,q Vector logical clock

(vector timestamp)
Message
Comparing Vector Timestamps
• VT1 = VT2,
if VT1[i] = VT2[i], for all i = 1, … , n
• VT1 ≤ VT2,
if VT1[i] ≤ VT2[i], for all i = 1, … , n
• VT1 < VT2,
if VT1 ≤ VT2 &
 j (1≤ j ≤ n where VT1[j] < VT2 [j])
• Then: VT1 is concurrent with VT2
if (not VT1 ≤ VT2 AND not VT2 ≤ VT1)

35
Vector Timestamps
(1,0,0) (2,0,0)
p1
a b m1

(2,1,0) (2,2,0)
Physical
p2
time
c d m2

(0,0,1) (2,2,2)
p3
e f
Summary of Synchronization
• Time synchronization important for distributed systems
• Cristian’s algorithm
• Berkeley algorithm
• NTP
• Relative order of events enough for practical purposes
• Lamport’s logical clocks
• Lamport’s vector clocks
Additional references
• http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ALGO-BASIC-SYNC
• Taylor & Francis. Computer Network Time Synchronization: The Network Time Protocol.
pp. 12–. ISBN 978-0-8493-5805-0.

38