1. Real-Time & MultiMedia Lab Synchronization Distributed System 2005.11.08 Jin-Seung,KIM

2. Real-Time & MultiMedia Lab Agenda Introduction Clock Synchronization Global Time and State Our simulation(Nomica & Jin-Seung) about Synchronization 3 Samples, 1 Simulation

3. Real-Time & MultiMedia Lab Introduction Communication not enough. Need cooperation  Synchronization Distributed synchronization needed for –Transactions (bank account via ATM) –Access to shared resource (network printer) –Ordering of events (network games where players have different ping times)

4. Real-Time & MultiMedia Lab Clock Synchronization When each machine has its own clock, an event that occurred after another event may nevertheless be assigned an earlier time Consider make –Compiling machine compares time stamps Same holds when using NFS mount Can we set all clocks in a distributed system to have the same time?

5. Real-Time & MultiMedia Lab Physical Clocks “ Exact ” time was computed by astronomers –Take “ noon ” for two days, divide by 24*60*60 → Mean solar second But … –Earth is slowing! (35 days over 300 million years) –Short term fluctuations (Magma core, and such) –Could take many days for average, but still erroneous Physicists take over (Jan 1, 1958) –Count transitions of cesium 133 atom 9,192,631,770 == 1 solar second –50 cesium 133 clocks averaged International Atomic Time (TAI) –To stop day from “ shifting ” (remember, earth is slowing) translate TAI into Universal Coordinated Time (UTC) UTC is broadcast (shortwave radio pulses)

6. Real-Time & MultiMedia Lab Clock Synchronization Algorithms Not every machine has UTC receiver –If one, then keep others synchronized Computer timers go off H times/sec, incr counter Ideally, if H=60, 216,000 per hour (dC/dt = 1) But typical errors, 10 – 5, so 215,998 to 216,002  Specs can give you maximum drift rate (  )  Every  t seconds, will be at most 2  t apart  If want drift of , re-synchronize every  /2   Various algorithms (next)

7. Real-Time & MultiMedia Lab Clock Synchronization Centralized Algorithms –Cristian ’ s Algorithm (1989) –Berkeley Algorithm (1989) Decentralized Algorithms –Averaging Algorithms (e.g. NTP) –Multiple External Time Sources

8. Real-Time & MultiMedia Lab Cristian ’ s Algorithm Well suited with systems in which one machine (time server) has a UTC receiver Every  /2 , ask server for time What are the problems? Major –Client clock is fast –What to do? Minor –Non-zero amount of time to sender –What to do?

9. Real-Time & MultiMedia Lab Cristian ’ s Algorithm

10. Real-Time & MultiMedia Lab The Berkeley Algorithm 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  Cristian’s and Berkeley’s are centralized. Problems?

11. Real-Time & MultiMedia Lab Decentralized Algorithms Periodically (every R seconds), each machine broadcasts current time Collect time samples for some time interval (S) Take average and set time Can discard m highest and m lowest, so m faulty clocks don ’ t hurt Can improve by computing (T1 ? T0)/2 –Need probes to obtain Used by Network Time Protocol (NTP) –Worldwide accuracy of 1-50 msec

12. Real-Time & MultiMedia Lab Lamport Timestamps Often don ’ t need time, but ordering a  b (happens before) Each processes with own clock with different rates. Lamport's algorithm corrects the clocks. Can add machine ID to break ties (impossible)

13. Real-Time & MultiMedia Lab Totally-Ordered Multicasting Total-ordered multicast: A multicast operation by which all messages are delivered in the same order to each receiver. Lamport Details –Each message is timestamped with the current logical time of its sender. (Use Lamport algorithm for adjusting local clocks) –Assume all messages sent by a sender are received in the order they were sent and that no messages are lost.

14. Real-Time & MultiMedia Lab Totally-Ordered Multicasting Lamport Details (cont): Receiving process puts a message into a local queue ordered according to timestamp. The receiver multicasts an ACK to all other processes. A message is processed from the local queue if no messages ahead and receive all ACKs from other processes. All processes will eventually have the same copy of the local queue ? consistent global ordering.

15. Real-Time & MultiMedia Lab Consistent Global State Need for state of distributed system, say, for deadlock or computation termination detection Cut represents the last event that has been recorded for each process How do ensure always a consistent cut? (A consistent cut) (An inconsistent cut)

16. Real-Time & MultiMedia Lab Consistent Global State Processes all connected (assume point-to-point connections). Any process can initiate state message (M) Organization of a process and channels for a distributed snapshot

17. Real-Time & MultiMedia Lab Consistent Global State Process Q receives M for the first time and records its local state. Sends M on all outgoing links Q records all incoming messages Q receives M for its incoming channel and finishes recording the state of the incoming channel Can then send state to initiating process System can still proceed normally

18. Real-Time & MultiMedia Lab Question & Demonstration Our simulation about Synchronization Process synchronization Semaphore Shared memory Message Queue Bank Account Simulation