Download Clock Synchronization in Distributed Systems: Algorithms and Logical Clocks and more Study notes Computer Science in PDF only on Docsity!
Clock Synchronization
- Physical clocks
- Logical clocks
- Vector clocks Physical Clocks Problem: Suppose we have a distributed system with a UTC- receiver somewhere in it we still have to distribute its time to each machine. UTC is Universal Coordinated Time, based on some atomic element (Cs) Basic principle:
- Every machine has a timer that generates an interrupt H times per second.
- There is a clock in machine p that ticks on each timer interrupt. Denote the value of that clock by Cp{t} , where t is UTC time.
- Ideally, we have that for each machine p , Cp{t} = t , or, in other words, dC/dt = 1
Clock Synchronization Algorithms In practice: 1 – ρ <= dC/dt <= 1 + ρ, for some small constant drift ρ Goal : Never let two clocks in any system differ by more than δ time units
synchronize at least every δ/( 2 ρ) seconds Clock Synchronization Idea 1: Every machine asks a time server for the accurate time at least once every d/(2r) seconds. Good solution, but
- need an accurate measure of round trip delay
- including interrupt handling and processing incoming messages. Idea 2: Let the time server scan all machines periodically, calculate an average, and inform each machine how it should adjust its time relative to its present time. Another good solution, you’ll probably get every machine in sync. Fundamental problem: You’ll have to take into account that setting the
time back is never allowed smooth adjustments.
Note: you don’t even need to propagate UTC time. Why not?
Logical Clocks Problem: How do we maintain a global view on the system’s behavior that is consistent with the happened-before relation? Solution: attach a timestamp C ( e) to each event e , satisfying the following properties:
- P1: If a and b are two events in the same process, and
a b, then we demand that C(a) < C(b).
- P2: If a corresponds to sending a message m , and b corresponds to receiving that message, then also C(a) < C(b). Problem: How to attach a timestamp to an event when there’s no
global clock maintain a consistent set of logical clocks, one
per process. Logical Clocks Each process Pi maintains a local counter Ci and adjusts this counter according to the following rules:
- For any two successive events that take place within Pi , Ci is incremented by 1.
- Each time a message m is sent by process Pi, the message receives a timestamp Tm = Ci
- Whenever a message m is received by a process Pj, Pj, adjusts its local counter Cj : Cj <= max {Cj + 1, Tm + 1}. Property P1 is satisfied by (1); Property P2 by (2) and (3).
Extension to Multicasting: Vector Timestamps Observation: Lamport timestamps do not guarantee that if C ( a) < C ( b) then a indeed happened before b. Why? We need vector timestamps for that.
- Each process Pi has an array Vi [1..n] , where Vi [j] denotes the number of events that process Pi knows have taken place at process Pj.
- When Pi sends a message m , it adds 1 to Vi [i], and sends Vi along with m as vector timestamp vt(m). Result : upon arrival, each other process knows Pi ’s timestamp. Question: What does Vi[j] = k mean in terms of messages sent and received? Extension to Multicasting: Vector Timestamps
- When a process Pj receives a message m from Pi with vector timestamp vt(m), it (1) updates each Vj [k] to max {Vj [k], V(m)[k]}, and (2) increments Vj [j] by 1
- Is the book correct?
- To support causal delivery of messages, assume you increment your own component only when sending a message. Then, Pj postpones delivery of m until:
- Vt (m)[i] = Vj [i] + 1
- Vt (m)[k] <= Vj [k] for k != i Example: Take V3 = [0,2,2], vt (m) = [1,3,0]. What information does P 3 have, and what will it do when receiving m (from P 1 )?
Global State ( 2 ) a) Organization of a process and channels for a distributed snapshot Global State ( 3 ) b) Process Q receives a marker for the first time and records its local state c) Q records all incoming message d) Q receives a marker for its incoming channel and finishes recording the state of the incoming channel
Election Algorithms Principle: An algorithm requires that some process acts as a coordinator. The question is how to select this special process dynamically. Note: In many systems the coordinator is chosen by hand (e.g. file servers). This leads to centralized solution single point of failure. Question: If a coordinator is chosen dynamically, to what extent can we speak about a centralized or distributed solution? Question: Is a fully distributed solution, i.e., one without a coordinator, always more robust than any centralized/coordinated solution? Election by Bullying Principle: Each process has an associated priority (weight). The process with the highest priority should always be elected as the coordinator. Issue: How do we find the heaviest process?
- Any process can just start an election by sending an election message to all other processes (assuming you don’t know the weights of the others).
- If a process P heavy receives an election message from a lighter process P light, it sends a take-over message to P light. P light is out of the race.
- If a process doesn’t get a take-over message back, it wins, and sends a victory message to all other processes.
