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/2min)

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

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.

1

2

3

2

3 3