Distribuerede systemer – 5. marts 2001 Presentation based on slides by Coulouris et al

Slides for Chapter 10: Time (and Global State) From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

Time - purpose zWe want to know when something happened, e.g., for the purpose of: yE-commerce. ymake utility. zAlgorithms may depend upon clock synchronization, e.g.: yMaintain consistency of distributed data. yEliminating the processing of duplicate updates. zNo global notion of time.

Time – system model zN processes: yEach executes on a single processor. yNo shared memory. yOnly communication means is exchange of messages. zpi has state si. zAn event is the occurrence of a single action, i.e., either: y An internal state-transforming action by pi, or y A communication action. ze (->i) e’ iff e occurs before e’ in pi.

Time - clocks zEach computer contains its own physical clock. zThe software clock Ci can be used to timestamp any event at pi. zClock skew: The instantaneous difference between the readings of any two clocks. zClock drift: Clocks count time at different rates and so diverge. zClock drift rate: The difference in reading between a given clock and a nominal perfect reference clock per time unit measured by the reference clock.

Time - skew between computer clocks in a distributed system

Time – Coordinated Universal Time (UTC) zAn international standard for timekeeping. zBased on atomic time. zSynchronizes with astronomical time using leap seconds. zUTC signals are synchronized and broadcast regularly from land-based radio stations and satellites. zComputers with receivers attached can synchronize their clocks with these timing signals.

Synchronizing physical clocks - basics zExternal synchronization: For each i, synchronize Ci with an authoritative, external source of time. zInternal synchronization: For each i,j, synchronize Ci and Cj with each other. zOther issues: Correctness, monotonicity, faulty clocks, crash failures, arbitrary failures.

Synchronizing physical clocks – in a synchronous system zIn a synchronous system, bounds are known for: yThe drift rates of clocks. yThe maximum message transmission delay. yThe time to execute each step of a process. zOne process sends the time t on its local clock to the other in a message m. The receiving process could set its time to: t + T(trans). zT(trans) is subject to variation and unknown – but within limits; T(trans) in [min,max]. zBetter for receiver to set its time to: t + (max+min)/2.

Synchronizing physical clocks – clock synchronization using a time server (Cristian’s method) m r m t p Time server,S p records total round-trip time T(round); p sets its time to t+T(round)/2; If minimal transmission time is known, accuracy can be calculated. Problem: single-point-of-failure. External synchronization

Synchronizing physical clocks – the Berkeley algorithm zInternal synchronization. zA coordinator computer is chosen to act as master. zMaster periodically polls the other computers (the slaves). zSlaves send back their clock values to master. zMaster calculates an average (taking the roundtrip times into account). zMaster sends the amount by which each individual slave’s clock requires adjustment. zThe algorithm eliminates readings from faulty clocks.

Synchronizing physical clocks – the Network Time Protocol (NTP) zChief design aims and features: yTo provide a service enabling clients across the Internet to be synchronized accurately to UTC. yTo provide a reliable service that can survive lengthy losses of connectivity. yTo enable clients to resynchronize sufficiently frequently to offset the rates of drift found in most computers. yTo provide protection against interference with the timeservice, whether malicious or accidental. zArchitecture: yA network of servers located across the Internet. yPrimary servers connected directly to time source. ySecondary servers synchronized with primary servers. yServers connected in logical hierarchy, synchronization subnet. yThree modes of sync.: Multicast, procedure-call, symmetric.

Synchronizing physical clocks – An example synchronization subnet in an NTP implementation Note: Arrows denote synchronization control, numbers denote strata.

Synchronizing physical clocks – Messages exchanged between a pair of NTP peers T i T i-1 T i-2 T i-3 Server B Server A Time mm' Time

Logical time and logical clocks - basics zSince we cannot synchronize clocks perfectly across a distributed system, we cannot in general use physical time to find out the order of any arbitrary pair of events occurring within it. zEvents can be ordered by the happened-before relation: yIf two events occurred at the same process pi, then they occurred in the order in which pi observes them (->i). yWhenever a message is sent between processes, the event of sending the message occurred before the event of receiving the message.

Logical time and logical clocks - example events occurring at three processes

Logical time and logical clocks – Lamport logical clocks and timestamps zA Lamport logical clock is a monotonically increasing software counter. zEach process pi keeps its own logical clock Li which is used to apply Lamport timestamps to events. zTo capture the happened-before relation ->, processes update their logical clocks and transmit the values of their logical clocks in messages as follows: yBefore each event at pi: Li := Li+1 yWhen pi sends a message m, it piggybacks t=Li. yWhen pj receives (m,t): Lj := max(Lj,t)+1. ze -> e’ => L(e) < L(e’).

Logical time and logical clocks – Lamport timestamps for example events

Logical time and logical clocks – Vector timestamps for example events Vi[i]: The number of events that pi has timestamped; Vi[j]: The number of events that have occurred at pj that pi has potentially been affected by, j <> i.

Summary zTime in general. zSynchronization of physical clocks: yIn a synchronous system. yCristian’s method. yThe Berkeley algorithm. yThe Network Time Protocol (NTP). zLogical time and logical clocks: yThe happened-before relation. yLamport’s logical clocks and Lamport’s timestamps. yVector timestamps.