real-time & multimedia lab synchronization distributed system 2005.11.08 jin-seung,kim
Post on 17-Jan-2016
217 Views
Preview:
TRANSCRIPT
Real-Time & MultiMedia Lab
Synchronization
Distributed System2005.11.08
Jin-Seung,KIM
Real-Time & MultiMedia Lab
Agenda
• Introduction• Clock Synchronization• Global Time and State• Our simulation(Nomica & Jin-Seung) about Synchronization 3 Samples, 1 Simulation
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)
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?
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)
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 2t apart
If want drift of , re-synchronize every /2
Various algorithms (next)
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
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?
Real-Time & MultiMedia Lab
Cristian’s Algorithm
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?
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
Real-Time & MultiMedia Lab
Lamport Timestamps• Often don’t need time, but ordering ab (happens before)
• Each processes with own clock with different rates.
• Lamport's algorithm corrects the clocks.
• Can add machine ID to break ties
(impossible)
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.
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.
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)
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
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
Real-Time & MultiMedia Lab
Question & Demonstration
• Our simulation about Synchronization• Process synchronization
• Semaphore• Shared memory• Message Queue• Bank Account Simulation
top related