DOC PREVIEW
Pitt CS 2510 - Clock Synchronization

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Clock Synchronization• Physical clocks• Logical clocks• Vector clocksPhysical ClocksProblem: Suppose we have a distributed system with a UTC-receiver somewhere in it we still have to distribute its time toeach 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 =12Clock Synchronization AlgorithmsIn 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ρ) secondsClock SynchronizationIdea 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 anaverage, 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?3The Berkeley Algorithma) The time daemon asks all the other machines for their clock valuesb) The machines answerc) The time daemon tells everyone how to adjust their clockThe Happened-Before RelationshipProblem: We first need to introduce a notion of orderingbefore we can order anything.The happened-before relation on the set of events in a distributed system is the smallest relation satisfying:• If a and b are two events in the same process, and a comes before b, then a b.• If a is the sending of a message, and b is the receipt of that message, then a b. • If a b and b c, then a c.• Is this a partial or total ordering of events in a system with concurrently operating processes?4Logical ClocksProblem: 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 bcorresponds 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 ClocksEach process Pimaintains a local counter Ciand adjusts this counter according to the following rules:1. For any two successive events that take place within Pi, Ciis incremented by 1. 2. Each time a message m is sent by process Pi, the message receives a timestamp Tm = Ci3. 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).5Extension to Multicasting: Vector TimestampsObservation: 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 Piknows have taken place at process Pj.• When Pisends a message m, it adds 1 to Vi [i], and sends Vialong 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 Pjreceives a message m from Piwith 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, Pjpostpones delivery of m until: – Vt(m)[i] = Vj[i] + 1– Vt(m)[k] <= Vj[k] for k != iExample: Take V3 = [0,2,2], vt(m) = [1,3,0]. What information does P3have, and what will it do when receiving m (from P1)?6Global State (1)Basic Idea: Sometimes you want to collect the current state of a distributed computation, called a distributed snapshot. It consists of all local states and messages in transit.Important: A distributed snapshot should reflect a consistent state:Global StateNote: any process P can initiate taking a distributed snapshot• P starts by recording its own local state• P subsequently sends a marker along each of its outgoing channels• When Q recieves a marker through channel C, its action depends on whether it has already recorded its local state: – Not yet recorded: it records its local state, and sends the marker along each of its outgoing channels– Already recorded: the marker on C indicates that the channel’s state should be recorded: all messages received before this marker and the time Q recorded its own state. • Q is finished when it has received a marker along each of its incoming channels.7Global State (2)a) Organization of a process and channels for a distributed snapshotGlobal State (3)b) Process Q receives a marker for the first time and records its local statec) Q records all incoming messaged) Q receives a marker for its incoming channel and finishes recording the state of the incoming channel8Election AlgorithmsPrinciple: 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/coordinatedsolution?Election by BullyingPrinciple: 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


View Full Document

Pitt CS 2510 - Clock Synchronization

Download Clock Synchronization
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Clock Synchronization and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Clock Synchronization 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?