Chapter 4
Chapter 4
Clock Synchronization
◼ 1
Introduction
◼ 2
What is synchronization?
◼3
1. Clock Synchronization
◼ 4
when each machine has its own clock, an event that occurred after
another event may nevertheless be assigned an earlier time
◼ 5
▪ Physical Clocks
▪ is it possible to synchronize all clocks in a distributed system?
▪ no; even if all computers initially start at the same time, they will get out of
synch after some time due to crystals in different computers running at
different frequencies, a phenomenon called clock skew
▪ how is time actually measured?
▪ Earlier astronomically; based on the amount of time it takes the earth to
rotate the sun; 1 solar second = 1/86400th of a solar day (24*3600 = 86400)
▪ it was later discovered that the period of the earth’s rotation is not constant;
the earth is slowing down due to tidal friction and atmospheric drag;
geologists believe that 300 million years ago there were about 400 days per
year; the length of the year is not affected, only the days have become
longer
▪ astronomical timekeeping was later replaced by counting the transitions of
the cesium 133 atom and led to what is known as TAI - International Atomic
Time (Temps Atomique International (French for International Atomic Time),)
◼ 6
▪ TAI was also found to have a problem; 86,400 TAI seconds are
behind a solar day by 3 msec, as a result of the day getting longer
everyday
▪ UTC (Universal Coordinated Time) was introduced by having leap
seconds whenever the discrepancy between TAI and solar time
grows to 800 msec
▪ UTC replaced the astronomical GMT(Greenwitch Mean Time)
▪ in some countries, UTC is broadcasted on shortwave radio and
satellites (as a short pulse at the start of each UTC second) for
those who need precise time; but one has to compensate for the
propagation delay
◼ 7
Clock Synchronization Algorithms
◼ 9
the relation between clock time and UTC when clocks tick at different rates
10
▪ If two clocks are drifting in the opposite direction, at a time t after they were
synchronized, they may be as much as 2 t apart
▪ if no two clocks should ever differ by more than , then clocks must be synchronized at
least every /2 seconds
▪ how is it done?
▪ Cristian’s Algorithm
▪ suitable when one machine has a UTC receiver; let us call this machine a time server
▪ no more than every /2 seconds, each machine sends a message to the time server
asking the current time
◼ 11
▪ first approximation: let the client set its clock to CUTC
▪ problems:
▪ message propagation time
▪ solution: try to estimate it as (T1-T0)/2 and add this to CUTC
▪ if we know how long it takes the time server to handle the
interrupt, the above can be improved; let the interrupt
handling time be I, then the new estimate will be (T1-T0-I)/2
▪ time must never run backward
▪ solution: introduce change gradually; if a timer is set to
generate 100 interrupts per second, it means 10 msec must
be added to the time; then make it say 9 (to slow it down) or
11 msec (to advance it gradually)
◼ 12
▪ The Berkley Algorithm
• In Cristian’s algorithm, the time server is passive; only
other machines ask it periodically
• In Berkley UNIX, a time daemon asks every machine from
time to time to ask the time
• it then calculates the average and sends messages to all
machines so that they will adjust their clocks accordingly
• suitable when no machine has a UTC receiver
• the time daemon’s time must be set periodically manually
◼ 13
a) the time daemon asks all the other machines for their clock values
b) the machines answer how far ahead or behind the time daemon they are
c) the time daemon tells everyone how to adjust their clock
◼ 14
2. Logical Clocks
▪ For some applications, it is sufficient if all machines agree on the same
time, rather than with the real time; we need internal consistency of the
clocks rather than being close to the real time
▪ hence the concept of logical clocks
• what matters is the order in which events occur
▪ Lamport Timestamps
▪ Lamport defined a relation called happens before
▪ a → b read as “a happens before b”; means all processes agree that
first event a occurs, then event b occurs
▪ this relation can be observed in two situations
▪ if a and b are events in the same process, and a occurs before b,
then a → b is true
▪ if a is the event of a message being sent by one process, and b is the
event of the message being received by another process, then a → b
is also true
◼ 15
▪ happens before is a transitive relation
▪ if a → b and b → c, then a → c
▪ if two events, x and y, happen in different processes that do
not exchange messages, then both x → y and y → x are not
true; these events are said to be concurrent; it means that
nothing can be said about the order of these events
▪ for every event a, we can assign a time value C(a) on which
all processes agree; if a → b, then C(a) < C(b)
◼ 16
▪ Lamport’s proposed algorithm for assigning times for processes
▪ consider three processes each running on a different machine,
each with its own clock
▪ the solution follows the happens before relation; each message
carries the sending time; if the receiver’s clock shows a value
prior to the time the message was sent, the receiver fast
forwards its clock to be one more than the sending time
◼ 17
a) three processes, each with its own clock; the clocks run at different rates
b) Lamport's algorithm corrects the clocks
◼ 18
▪ additional requirements
▪ between two events, the clock must tick at least once, i.e., a process
that sends or receives two messages in succession must advance its
clock by one tick
▪ no two events must occur at exactly the same time; if so attach the
number of the process; e,g., if events happen in processes 1 and 2 at
time 40, then we have 40.1 and 40.2
▪ with these requirements, assigning time to all events in a distributed
system is subject to the following conditions
1. if a → b in the same process, then C(a) < C(b)
2. if a and b represent the sending and receiving of a message,
respectively, then C(a) < C(b)
3. for all distinctive events a and b, C(a) C(b)
◼ 19
▪ Example: Totally-Ordered Multicasting
▪ assume a bank database replicated across several cities for
performance; a query is always forwarded to the nearest copy
▪ let us have a customer with $1000 in her account, she is in city A and
wants to add $100 to her account (update 1)
▪ a bank employee in city B initiates an update of increasing accounts by 1
percent interest (update 2)
▪ both must be carried out at both copies of the database
▪ due to communication delays, if the updates are done in different
order, the database will be inconsistent (city A = $1111, city B =
$1110)
◼ 20
▪ situations like these require a Totally-Ordered Multicast, i.e., all
messages are delivered in the same order to each receiver
▪ Lamport timestamps can be used to implement totally-ordered
multicasts
• Timestamp each message
▪during multicasting, send a message also to the sender
▪assume messages from the same sender are received in the order
they are sent and no message is lost. all messages are put in a local
queue ordered by timestamp
▪each receiver multicasts an acknowledgement
▪then all processes will have the same copy of the local queue
▪a process can deliver a queued message to the application it is
running only when that message is at the top of the queue and has
been acknowledged by each other process
◼ 21
▪ Vector Timestamps
▪ with Lamport timestamps a → b does not necessarily
mean a happens before b; only that all processes agree;
but they ensure total ordering
▪ it also doesn’t tell us causality of events. vector
timestamps are designed for this purpose, read more
about vector time stamping.
◼ 22
Mutual Exclusion
▪ when a process has to read or update shared data (quite often to
use a shared resource such as a printer, a file, etc.), it first enters a
critical region to achieve mutual exclusion
▪ in single processor systems, critical regions are protected using
semaphores, monitors, and similar constructs
▪ how are critical regions and mutual exclusion implemented in
distributed systems?
▪ three algorithms: centralized, distributed, and token ring
▪ A Centralized Algorithm
▪ a coordinator is appointed and is in charge of granting
permissions
▪ three messages are required: request, grant, release
23
a) process 1 asks the coordinator for permission to enter a critical
region; permission is granted
b) process 2 then asks permission to enter the same critical region; the
coordinator does not reply (could also send a no message; is
implementation dependent), but queues process 2; process 2 is
blocked
c) when process 1 exits the critical region, it tells the coordinator, which
then replies to 2
24
▪ the algorithm
▪ guarantees mutual exclusion
▪ is fair - first come first served
▪ no starvation
▪ easy to implement; requires only three messages: request, grant, release
▪ shortcoming: a failure of the coordinator crashes the system (specially if
processes block after sending a request); it also becomes a performance
bottleneck
▪ A Distributed Algorithm
▪ assume that there is a total ordering of all events in the system, such as using
Lamport timestamps
▪ when a process wants to enter a critical region it builds a message
(containing name of the critical region, its process number, current time) and
sends it to everyone including itself
▪ the sending of a message is assumed to be reliable; i.e., every message is
acknowledged
25
▪ when a process receives a request message
1. if the receiver is not in a critical region and does not want to
enter it, it sends back an OK message to the sender
2. if the receiver is already in the critical region, it does not reply;
instead it queues the request
3. if the receiver wants to enter the critical region but has not yet
done so, it compares the timestamp of the message it sent with
the incoming one; the lowest wins; if the incoming message is
lower, it sends an OK message; otherwise it queues the
incoming message and does not do anything
▪ when the sender gets a reply from all processes, it may enter into
the critical region
▪ when it finishes it sends an OK message to all processes in its
queue
26
▪ is it possible that two processes can enter into the critical region at the
same time if they initiate a message at the same time? NO
a) two processes (0 and 2) want to enter the same critical region at the
same moment
b) process 0 has the lowest timestamp, so it wins
c) when process 0 is done, it sends an OK message, so process 2 can
now enter into its critical region
27
▪ mutual exclusion is guaranteed
▪ the total number of messages to enter a critical region is
increased to 2(n-1), where n is the number of processes
▪ no single point of failure; unfortunately n points of failure
▪ we also have n bottlenecks
▪ hence, it is slower, more complicated, more expensive, and
less robust than the previous one; but shows that a
distributed algorithm is possible
◼ 29
▪ The Bully Algorithm (the biggest person wins)
▪ when a process (say P4) notices that the coordinator is no longer
responding to requests, it initiates an election as follows
1. P4 sends an ELECTION message to all processes with higher
numbers (P5, P6, P7)
▪ if a process gets an ELECTION message from one of its lower-
numbered colleagues, it sends an OK message to the sender
and holds an election
2. if no one responds, P4 wins the election and becomes a
coordinator
3. if one of the higher-ups answers, this new process takes over
◼ 30
a) Process 4 holds an election
b) Process 5 and 6 respond, telling 4 to stop
c) Now 5 and 6 each hold an election
◼ 31
d) Process 6 tells 5 to stop
e) Process 6 wins and tells everyone
▪ the last one will send a message to all processes telling them that it is a
boss
▪ if a process that was previously down comes back, it holds an election
◼ 32