Synchronization I

1. Synchronization I CSE5306 Lecture Quiz 16 due at 5 PM Saturday, 4 October 2014

2. 6 Synchronization • Cooperating processes march in lock step, as they share resources; e.g., printer, mailbox. • Synchronization is paying attention to the passage of time or ordering of events. • A group of processes may elect a coordinator.

3. 6.1 Clock Synchronization • UNIX’ make process recompiles all source (.c) files, with later timestamps than their object (.o) files. If those files are distributed among many processors, then all must agree on a single time standard. • Security brokerages, security auditors and collaborative sensors have similar problems.

4. 6.1.1 Physical Clocks • Every computer’s high-frequency crystal-controlled oscillator decrements a counter to zero, which interrupts the processor. Then the counter reloads a maximum count from a holding register that ensures a “clock tick” every 1/60 second. • The earth spins slower every year, but the duration of a year is (assumed) fixed. 300M years ago, each year had 400 days. • International Atomic Time (TAI) is the mean number of Cesium-133 clock ticks since 1/1/1958, divided by 9,192,631,770 ticks/day. TAI adds a leap second to Universal Coordinated Time, twice each year, when UTC misses 12-Noon by more than 800 milliseconds. Colorado radio station WWV broadcasts UTC time with +10msec accuracy, but our more accurate computers prefer to add a leap second when UTC does.

5. 6.1.2 Global Positioning System • 29 GPS satellite broadcasts of their positions and time enable a ground-based diversity receiver to triangulate its position with 10m accuracy. • Only four simultaneous equations in latitude, longitude, altitude and relative time can be solved for actual time and position, but the averages of 12 satellite equations are more accurate. • By slowly averaging out atmospheric aberrations, a stationary GPS receiver achieves 30-nanosecond time precision and 1-centimeter position accuracy. Robotic bull dozers and land surveyors enjoy the same precision, when they correct GPS data with locally calculated atmospheric data.

6. R U O K ? Match the following terms with their definitions. • Synchronization. __ • Coordinator. __ • UNIX’ makeprocess. __ • International Atomic Time (TAI). __ • Leap second. __ • Universal Coordinated Time (UTC). __ • Global Positioning System (GPS). __ • Diversity receiver. __ • International standard time continuously broadcast by Colorado radio station WWV. • Paying attention to the passage of time and the chronological order of events. • Added to TAI semiannually, like Gregory’s February 29th in every fourth year. • Automatically recompiles all .c files in a project, whose .o files are obsolete. • A radio that listens to many transmitters at once. • A process that arbitrates other’s access to a shared resource. • Many low earth orbit (LEO) satellites continuously broadcasting their positions and time of day. • International standard time continuously broadcast by a Paris radio station.

7. 6.1.3 Clock Synchronization Algorithms • Modern computer timers have a maximum drift rate of ρ = 0.001%. • A 60Hz timer nominally generating 60x60x60 = 216000 ticks/hour can gain or lose 2.16 ticks/hour; i.e., 1 − ρ<dC/dt< 1 + ρ. • Two timers drifting in opposite directions can be up to 2ρ Δt apart after Δt seconds. • If two computers’ times must agree within δ seconds, their software must resynchronize their timers every δ/2ρ seconds.

8. Network Time Protocol • Client A repeatedly queries a distant WWV time server B in a timestamped message, and B replies with its own timestamped message. • Correcting the reported times for observed propagation delays over many such queries reveals A is 50msec slow. • Client A subtracts a millisecond from every timer interval till its local time is correct.

9. Berkeley Algorithm • The time server queries all clients regularly and tells all of them their average time. • Each client gradually adjusts its timer into agreement. • Average time need not track UTC time.

10. WiFi Clock Synchronization • Resource constraints, no multi-hop routing and energy conservation limit WiFi laptops. • In reference broadcast synchronization (RBS), the time server assumes all receivers’ propagation and network interface time delays are the same. • The time message’s timestamp allows each receiver to measure its app’s delivery time, and to offset (not adjust) its local time accordingly. • Occasionally offset grows large, and local time is adjusted with minimal energy consumption.

11. 6.2 Logical Clocks • In the foregoing make example, two processors need only agree that a .c source file is newer than a .o binary file. • Logical clocks can answer that question with minimal effort. • Lamport’s algorithm synchronizes logical clocks. • An extension of his algorithm uses vector timestamps.

12. R U O K ? 9. If your and my modern computers’ timers must never deviate by more than 6 seconds, how often should we resynchronize them? __ a. 2.5 min. b. 3 hrs. c. 3.5 da. d. 4 wks.

13. R U O K ? 10. “The great thing about standards is there are so many to choose from!” Why are there two different international time standards in Colorado and Paris? __ • Paris’ brand new cesium 133 atomic clock is more accurate than Colorado’s grandfather clock, which probably will run down and be abandoned soon. • As the historic diplomatic center of the world, the French are confident that they can persuade all 200 nations in the world to use their clearly superior clock in due time. • It really doesn’t matter how accurate a clock is, as long as everyone agrees to use it. • Every computer is an uncertain propagation delay away from any given timing source, so computer synchronization to the cesium atom’s standard +1/9,192,631,770-second precision is nonsense.

14. R U O K ? Match the following time protocols with their descriptions below. 11. Network Time Protocol. __ 12. Berkeley Algorithm. __ 13. WiFiSynchronization. __ 14. Logical clocks. __ • Application continually computes an offset between its local time and the time server’s message timestamps, adding the offset to its timestamps. When the offset grows too large, the app changes its local clock. • Correct WWV server’s reported time for the propagation delays evident in the request and reply message timestamps. • Server continually averages clients’ current times, and clients speed up or slow down their clocks till all agree with the current average. • Get your peers to agree on the order of important events, and forget about what time it is.

15. 6.2.1 Lamport’s Logical Clocks • Lamport reads a  b as “a happens before b”; e.g., for every message, sent  received. • If neither x  y nor y  x, then x and y are concurrent. • If a  b and b  c, then a  c. • If a  b and C(x) is x’s clock time, then C(b) > C(a). • Initially running at different rates in the (left) figure above, the three processors’ clocks must be adjusted (center), so that every timestamped message’s received clock time > its sent clock time. • Even in 1 processor (right), there are different clocks at the middleware’s application- and network-layer interfaces.

16. Totally Ordered Multicasting New York San Francisco • If a bank customer adds $100 to his $1000 San Francisco bank account at the same time the bank adds 1% interest to his replicated account in New York, propagation delays could make the San Francisco server’s balance $1111 and the New York server’s balance $1110. Oops. • Totally ordered multicasting (A.K.A. state machine replication) holds each every timestamped message in a local queue, until all senders receive acknowledge-ments. • Then all messages are given to local applications in timestamp order, and all acknowledgements are discarded.

17. 6.2.2 Vector Clocks • From C(m1) < C(m2) and C(m2) < C(m3) above, Lamport’s logical clocks can deduce that message m1 preceded m3. • Vector clocks canfurther deduce that m3 was caused by both m1 and m2, but m2 was not caused by m1. • Event a is said to “causally precede” event b, if the vector clocks VC(a) and VC(b) assigned to events a and b have the relationship VC(a) < VC(b). • Vector clock properties: • The local logical clock at process Pi, VCi[i] records the number of events that have occurred at Pi. • If VCi[j] = k, then Pi knows k events have occurred at Pj, and those k events are Pi‘s knowledge of the local time at Pj. • Example above [please check this]: • Before sending m1, P1 executes VC1[1] = VC1[0] + 1 = 6 + 1 = 7. • When P1 sends m1 to P2, P1 sets ts(m1) = VC1[1] = 7. • Upon receiving m1, P2 sets VC2[1] = max{ VC2[0], ts(m1) } = max{ 16, 7} = 16. • Repeat steps 1 through 3 for P2 and P3’s messages m2 through m5 above. • ts(a)[2] – 1 events (of all processes) causally precede event a in process P2.

18. Enforcing Causal Communication • Causally-ordered multicasting delays message delivery to the application layer (see m* ricochet above), until all messages that caused it also have been delivered; i.e., • ts(m)[i] = VCj[i] + 1 (That is, m is the next message Pj expects from Pi). • ts(m)[k] = VCj[k] for all k ≠ i (That is, when Pi sent m, Pj already had seen all messages Pi had seen).

19. Note: Ordered Message Delivery • Should middleware or the application handle ordered message delivery…? • Middleware should not, because it cannot actually read the messages: • Thus, middleware could mark two totally unrelated messages from the same sender as causally related. • Or it could fail to identify causally related messages from different senders, who also are communicating over an external medium. • The application should not, because message delivery is outside its design scope (i.e., the “end-to-end argument).

20. R U O K ? 15. Should middleware or the application handle ordered message delivery? __ • Middleware should not, because it might mark two totally unrelated messages from the same sender as causally related. • Middleware should not, because it might fail to identify causally related messages from different senders, who also are communicating over an external medium. • The application should not, because message delivery violates its design scope. • The application should, because it can read the messages.

21. 6.3 Mutual Exclusion • Concurrency and collaborations among distributed systemssuggests that many processes often share resources. • Mutually exclusive access prevents the resources’ corruption or inconsistent behaviors. • Hey, I don’t want my printout in the middle of yours!

22. 6.3.1 MutexOverview • Token-based mutex: • Whoever owns the token gets the printer. • After your print job, please pass the token to the next person in line (me). • There is no starvation (waiting forever) or deadlocks. • But the token can be lost, if its owner crashes. • Permission-based mutex: • I ask all other users’ permission to use the printer.

23. 6.3.2 Centralized Algorithm • I ask the coordinator process’ permission to use the printer. • If it is idle, the coordinator says Yes. • If it is busy, the coordinator says No, or delays reply till the current user releases it. • Only three simple messages provide access: request, grant and release. • But a dead coordinator can starve requesters, who I/O-block while waiting for the resource. And an overworked coordinator can limit performance.

24. 6.3.3 Decentralized Algorithm • Many replicated resources and their DHT-based coordinators (allocated around a Chord ring) perform better and are more reliable than just one. • A process’ resource request is granted, if a majority of coordinators agree, or immediately denied if they don’t. • But what if a coordinator crashes, forgets its granted request, and grants a conflicting request right after its recovery? • Assuming each of 32 coordinators lives 3 hours, requests are 10-seconds apart, and 24 affirmative votes are required to grant each request, statistics says such a failure has a 10−40 probability (pp.254-5).

25. 6.3.4 Distributed Algorithm • Lamport’s clock synchronization scheme offers a deterministic alternative: • I send a timestamped resource access request to all processes. • If you don’t need the resource, you say OK. • If you are using it, you delay your OK till you are finished with it. • If you also have requested it, you say OK only if my timestamp is earlier than yours. • I access it, only after everyone answers OK. And I say OK to all their pending requests, after I finish with it. • Unfortunately, this algorithm is slower, more complicated, more expensive and less robust than the centralized one. But it stimulates thought about distributed systems….

26. R U O K ? Match the following message ordering terms with their descriptions below. 16. Lamport’s algorithm. __ 17. Vector clocks. __ 18. Totally ordered multicasting. __ 19. Causally ordered multicasting. __ • Delay each application layer message, till all messages that caused it have been delivered. • Delay all application layer messages, till all senders receive Acks. • Adjust all processors’ clocks so that every timestamped message’s received clock time > its sent clock time. • Deduce that event a “causally precedes” event b, if vector clocks VC(a) and VC(b) assigned to events a and b have the relationship VC(a) < VC(b).

27. R U O K ? Match the following mutual exclusion terms with their definitions below. 20. Token-based mutex. __ 21. Permission-based mutex. __ 22. Centralized algorithm. __ 23. Decentralized algorithm. __ 24. Distributed algorithm. __ • Ask the coordinator process’ permission to use resource. Dead coordinator starve requesters. • Requester with earliest timestamp gets resource, if all goes well. • Token owner gets resource, and passes it on when finished. Token gets lost, if owner crashes. • Many replicated resources and their DHT-based coordinators perform better and more reliably than one. • Ask everybody’spermission to use the resource.