DETAIL STUDY OF CLOCK SYNCHRONIZATION

Clock synchronization is a problem from computer science and engineering which deals
with the idea that internal clocks of several computers may differ. Even when initially set
accurately, real clocks will differ after some amount of time due to clock drift, caused by
clocks counting time at slightly different rates. There are several problems that occur as a
repercussion of rate differences and several solutions, some being more appropriate than
others in certain contexts.

Problems

Besides the incorrectness of the time itself, there are problems associated with clock skew
that take on more complexity in a distributed system in which several computers will
need to realize the same global time.

For instance, in Unix systems the make command is used to compile new or modified
code without the need to recompile unchanged code. The make command uses the clock
of the machine it runs on to determine which source files need to be recompiled. If the
sources reside on a separate file server and the two machines have unsynchronized clocks,
the make program might not produce the correct results.

Solutions

In a centralized system the solution is trivial; the centralized server will dictate the system
time. Cristian's algorithm and the Berkeley Algorithm are some solutions to the clock
synchronization problem in a centralized server environment. In a distributed system the
problem takes on more complexity because a global time is not easily known. The most
used clock synchronization solution on the internet is the Internet Network Time Protocol
(NTP) which is a layered client-server architecture based on UDP message passing.
Lamport timestamps and Vector clocks are concepts of the logical clocks in distributed
systems.

Clock Synchronization: Sources of Accurate Timing Signals

International Atomic Time is based on very accurate physical clocks (drift rate 10-13).

Coordinated Universal Time (UTC) is an international standard for time keeping.

It is broadcast from radio stations on land and satellite (e.g. GPS).

Computers with receivers can synchronize their clocks with these timing signals.

Signals from land-based stations are accurate to about 0.1-10 millisecond.

Signals from GPS are accurate to about 1 microsecond.

Difficulties in clock synchronization in DS
– Not all sites have direct access to accurate time source such as a GPS receivers due
to the cost.
– Sites has to synchronize their local clocks with those have more accurate time.
– Synchronization needs to be done periodically due to clock drift: rate is change in
the offset (difference in reading) between the clock and a normal perfect reference
clock per unit of time measured (about 10-6 or 1 sec. in 11.6 days).

If a site’s clock is ahead of the reference (time server) to which it synchronizes to, it
cannot be simply set back (why?).

This may have effect that a event that has happened but its time-stamp is in the future
 (Example: compiler and UNIX make).

For process pi
– Ci(t) – software clock
– Hi(t) – Hardware clock, I.e., the time given by hardware clock

Thus: Ci(t) = αH(t)+ β

Various notions of correctness for clocks have been suggested.

It is common to define a hardware clock H to be correct if its drifts fall within a known
bound ρ > 0 (e.g. for real-time t’ and t, t’>t).

(1- ρ )(t’-t) ≤ H(t’) – H(t) ≤ (1+ρ )(t’-t)

External and Internal Clock Synchronization

External synchronization
– A computer’s clock Ci is synchronized with an external authoritative time source S,
so that:
– |S(t) - Ci(t)| < D for i = 1, 2, … N over an interval, I of real time
– The clocks Ci are accurate to within the bound D.

Internal synchronization
– The clocks of a pair of computers are synchronized with one another so that:
– | Ci(t) - Cj(t)| < D for i = 1, 2, … N over an interval, I of real time
– The clocks Ci and Cj agree within the bound D.

Internally synchronized clocks are not necessarily externally synchronized, as they
may drift collectively.

if the set of processes P is synchronized externally within a bound D, it is also internally

synchronized within bound 2D.
Cristian's algorithm for clock synchronization.

Cristian's algorithm relies on the existence of a time server.The time server maintains its
clock by using a radio clock or other accurate time source, then all other computers in the
system stay synchronized with it. A time client will maintain its clock by making a
procedure call to the time server. Variations of this algorithm make more precise time
calculations by factoring in network propagation time.

Client C requests time in Request message sent to time server S, then it receives time
value t in message CUTC from S. t is the current time in S before sending back CUTC to
C.

Let Ttrans be time taken for CUTC message from S to C, then C should set its time to t +
Ttrans .

Ttrans can be variant. You may say: Ttrans = min+x, x ≥ 0 and min = time of message
transmission if no interference of other process and no other messages, but x is
unknown!

Solution (See the next slide): (1) Record total round trip time as Tround (between
sending Request and receiving CUTC,, i.e., T1-T0) (2) If the time received in Request
message is t, then C can estimate its time as: t + Tround/2.

Getting the current time from a time server.

Keep in mind: C’s time is t + Tround/2.

Let the minimum transmission time be min, and min is known.

Therefore, t’ (the time in S when C receives CUTC ) lies in the range

[t+min, t+Tround  min]

t+ Tround min  (t+min) = Tround 2min

The accuracy for this time adjustment is ±(Tround/2min)

Problem: single-server failure.

Solution: providing group synchronization time servers

Berkeley algorithm for clock synchronization

This algorithm is more suitable for systems where a radio clock is not present, this system
has no way of making sure of the actual time other than by maintaining a global average
time as the global time. A time server will periodically fetch the time from all the time
clients, average the results, and then report back to the clients the adjustment that needs
be made to their local clocks to achieve the average. This algorithm highlights the fact
that internal clocks may vary not only in the time they contain but also in the clock rate.
Often, any client whose clock differs by a value outside of a given tolerance is
disregarded when averaging the results. This prevents the overall system time from being
drastically skewed due to one erroneous clock.

In Berkeley UNIX, one of a group sites (computers) is chosen as coordinator, (master or

time server).

(1) The master (actually a time daemon in the master) periodically polls the other sites
(slaves) to ask what time it is there, by telling its own time (the time in master) to these
slaves.

(2) The slaves response with how far ahead or behind the time daemon they are, that
is, the difference between its time and the time in master.

(3) Based on the replies from the slaves, the master averages the time obtained
(including its own).

(4) The master sends time rate adjust value (+ or -) to slaves, requesting them to adjust
their time rate.

The time daemon asks all the other machines for their clock values

• The machines answer

The time daemon tells everyone how to adjust their clock

Clock Sampling Mutual Network Synchronization

This algorithm is a class of mutual network synchronization algorithm in which no master

or reference clocks are needed. All clocks equally participate in the synchronization of the
network by exchanging their timestamps using regular beacon packets. CS-MNS is
suitable for distributed and mobile applications. It has been shown to be scalable, accurate
in the order of few microseconds, and compatible to IEEE 802.11 and similar standards.[3]

Clock Synchronization with NTP

Synchronization clock: Network Time Protocol (NTP)

Stratum 1: Primary server (PS) sync directly with UTC sources.

Stratum 2: Secondary servers (SS) sync directly to PS.

Stratum 3: Lowest servers (LS) execute in user sites sync with SS.

Accuracy: the number of levers (strata).

2 2

3 3 3

Clock Synchronization: Network Time Protocol

Multiple servers provide for redundancies and hence availability of time sources and
fault-tolerance.

NTP synchronizes with one another in one of three modes:
–Multicast: Used on LAN. One or more servers periodically broadcast the time to servers
running in workstations which set their clocks assuming a small delay. Accuracy is low.
–Procedure-call: Similar to Cristian’s method. Workstations ask the server the time.
Accuracy is higher than multicast.
–Symmetric mode: Used by high level to achieve highest accuracy. A pair of servers
exchange messages bearing timing information.