Post on 18-Jan-2016
Physical clock synchronization
Question 1.
Why is physical clock synchronization important?
Question 2.
With the price of atomic clocks or GPS coming down,
should we care about physical clock synchronization?
Classification
Types of Synchronization
External Synchronization Internal Synchronization Phase Synchronization
Types of clocks
Unbounded 0, 1, 2, 3, . . .
Bounded 0,1, 2, . . . M-1, 0, 1, . . .
Unbounded clocks are not realistic, but are easier to
deal with in the design of algorithms. Real clocks are
always bounded.
Terminologies
R R
Newtonian time
c
l
o
c
k
t
i
m
e
clock 1
clock 2
≤ δ
= drift rate ρ
What are these?Drift rate ρClock skew δResynchronization interval R
Max drift rate ρ implies: (1- ρ) ≤ dC/dt < (1+ ρ)
Challenges(Drift is unavoidable)Accounting for propagation delayAccounting for processing delay
Faulty clocks
Internal synchronization
Berkeley Algorithm
A simple averaging algorithm
that guarantees mutual
consistency |c(i) - c(j)| < δ
Step 1. Read every clock in the system.Step 2. Discard outliers and substitute
them by the value of the local clock. Step 3. Update the clock using the
average of these values.
Resynchronization interval will depend on the drift rate.
Internal synchronization
Lamport and Melliar-Smith’s
averaging algorithm handles
byzantine clocks too
Assume n clocks, at most t are faulty
Step 1. Read every clock in the system.Step 2. Discard outliers and substitute them by the
value of the local clock. Step 3. Update the clock using the average of
these values.
Synchronization is maintained if n > 3t
Why?
i j
k
c
c+ δ
-c δ
-2c δ
A faulty clocks exhibits 2-faced or byzantine behavior
Bad clock
Internal synchronization
Lamport & Melliar-Smith’s algorithm (continued) The maximum difference between
the averages computed by two
non-faulty nodes is (3tδ / n)
To keep the clocks synchronized,
3tδ / n < δ
So, 3t < n
i j
k
c
c+ δ
-c δ
-2c δ
B a d c l o c k s
k
Cristian’s method
Client pulls data from a time server
every R unit of time, where R < δ / 2ρ.
(why?)
For accuracy, clients must compute
the round trip time (RTT), and
compensate for this delay
while adjusting their own clocks.
(Too large RTT’s are rejected)
Timeserver
External Synchronization
Network Time Protocol (NTP)
Tiered architecture Broadcast mode
- least accurate
Procedure call
- medium accuracy
Peer-to-peer mode
- upper level servers use this for max accuracy
Timeserver
The tree can reconfigure itself if some node fails.
Level 1Level 1
Level 1Level 0
Level 2Level 2
Level 2
P2P mode of NTPLet Q’s time be ahead of P’s time by δ. Then
T2 = T1 + TPQ + δT4 = T3 + TQP - δ
y = TPQ + TQP = T2 +T4 -T1 -T3 (RTT)
δ = (T2 -T4 -T1 +T3) / 2 - (TPQ - TQP) / 2
So, x- y/2 ≤ δ ≤ x+ y/2
T2
T1 T4
T3Q
P
Ping several times, and obtain the smallest value of y. Use it to calculate δ
x Between y/2 and -y/2
Problems with Clock adjustment
1. What problems can occur when a clock value isAdvanced from 171 to 174?
2. What problems can occur when a clock value is Moved back from 180 to 175?
Mutual Exclusion
CS
CS
CS
CSp0
p1
p2
p3
Why mutual exclusion?
Some applications are:
1. Resource sharing
2. Avoiding concurrent update on shared data
3. Controlling the grain of atomicity
4. Medium Access Control in Ethernet
5. Collision avoidance in wireless broadcasts
Specifications
ME1. At most one process in the CS. (Safety property)ME2. No deadlock. (Safety property)ME3. Every process trying to enter its CS must eventually succeed.
This is called progress. (Liveness property)
Progress is quantified by the criterion of bounded waiting. It measuresa form of fairness by answering the question: Between two consecutive CS trips by one process, how many times other processes can enter the CS?
There are many solutions, both on the shared memory model and the message-passing model
Message passing solution:Centralized decision making
clients
Clientdo true
send request;wait until a reply is received;enter critical section (CS)send release;<non-CS activities>
od
Serverdo request received and not busy send reply; busy:= true request received and busy enqueue sender release received and queue is empty busy:= false release received and queue not empty send reply
to the head of the queueod
busy: boolean
server
queue
req replyrelease
Comments
- Centralized solution is simple.
- But the server is a single point of failure. This is BAD.
- ME1-ME3 is satisfied, but FIFO fairness is not guaranteed. Why?
Can we do better? Yes!
Decentralized solution 1:Lamport’s algorithm
{Life of each process}
1. Broadcast a timestamped request to all.
2. Request received enqueue sender in local Q;.
Not in CS send ack
In CS postpone sending ack (until
exit from CS).
3. Enter CS, when
(i) You are at the head of your own local Q
(ii) You have received ack from all processes
4. To exit from the CS,
(i) Delete the request from Q, and
(ii) Broadcast a timestamped release
5. Release received remove sender from local Q.
0 1
2 3
Q0 Q1
Q2 Q3
Completely connected topology
Can you show that it satisfies all the properties (i.e. ME1, ME2, ME3) of a correct solution?