Download Synchronizing Time in Concurrent Systems: Physical Clocks and Algorithms and more Study notes History of Education in PDF only on Docsity!
PagePage 11
Clock Synchronization: Physical Clocks
[email protected]^ Paul Krzyzanowski
Distributed Systems
Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Page 2
What’s it for?
- Temporal ordering of events produced by concurrent processes
- Synchronization between senders and receivers of messages
- Coordination of joint activity
- Serialization of concurrent access for shared objects
PagePage 33
Physical clocks
Page 4
Logical vs. physical clocks
Logical clock keeps track of event ordering – among related (causal) events
Physical clocks keep time of day – Consistent across systems
Page 5
Quartz clocks
- (^1880) – Curie brothers: Piezoelectric effect
- – Squeeze a quartz crystal & it generates an electric fieldApply an electric field and it bends
- (^1929) – Resonator shaped like tuning fork: Quartz crystal clock
- – LaserStandard resonators accurate to 6 parts per million at 31-trimmed to vibrate at 32,768 Hz ° C
- – Watch will gain/lose < ½ sec/dayStability > accuracy: stable to 2 sec/month
- Good resonator • Frequency changes with age, temperature, and acceleration can have accuracy of 1 second in 10 years
Page 6
Atomic clocks
- Second is defined as 9,192,631,770 periods of radiation corresponding to the transition
between two hyperfine levels of cesium- 133
- Accuracy: better than 1 second in six million years
- NIST standard since 1960
Page 7
UTC
- UT0 – Mean solar time on Greenwich meridian
- UT1^ –^ Obtained from astronomical observation
- UT2^ –^ UT0 corrected for polar motion
- UT1 corrected for seasonal variations in Earth’s rotation
- UTC – Civil time measured on an atomic time scale Page 8
UTC
- • Coordinated Universal TimeTemps Universel Coordonné
- – Kept within 0.9 seconds of UT1Atomic clocks cannot keep mean time
- Mean time is a measure of Earth’s rotation
Page 9
Physical clocks in computers
Real driven by a quartz oscillator-time Clock: CMOS clock (counter) circuit
- battery backup to continue measuring time when power is off
OS generally programs a timer circuit to generate an interrupt periodically
- e (Linux 2.6+ adjustable up to 1000 Hz).g., 60, 100, 250, 1000 interrupts per second
- – Programmable Interval Timer (PIT)Interrupt service procedure adds 1 to a counter in memory – Intel 8253, 8254 Page 10
Problem
Getting two systems to agree on time – Two clocks hardly ever agree
- Quartz oscillators oscillate at slightly different frequencies
Clocks tick at different rates – Create ever-widening gap in perceived time
Difference between two clocks at one point in time – Clock Skew
Page 11
Sept 18, 2006 8:00:
Page 12
Oct 23, 2006 8:00: Skew = +84 seconds^ 8:01:24^ 8:01: +84 seconds/35 days Drift = +2.4 sec/day +108 seconds/35 days^ Skew = +108 seconds Drift = +3.1 sec/day
Page 19
Compensating for a fast clock
UTC time, t
Computer’s time,
C
Linear compensating function applied
skew^ Clock synchronized
Page 20
Compensating for a fast clock
UTC time, t
Computer’s time,
C
Page 21
Resynchronizing
After synchronization period is reached – Resynchronize periodically
- Successive application of a second linear compensating function can bring us closer to true slope
Keep track of adjustments and apply continuously
- e.g., UNIX adjtime system call
Page 22
Getting accurate time
- Attach GPS receiver to each computer ± 1 msec of UTC
- Attach WWV radio receiver Obtain time broadcasts from Boulder or DC
- Attach GOES receiver^ ±^ 3 msec of UTC (depending on distance) ± 0.1 msec of UTC
Not practical solution for every machine – Cost, size, convenience, environment
Page 23
Getting accurate time
Synchronize from another machine – One with a more accurate clock
Machine/service that provides time information:
Time server
Page 24
RPC
Simplest synchronization technique – Issue RPC to obtain time
Does not account for network or processing latency
client what’s the time? server
Page 25
Cristian’s algorithm
Compensate for delays – Note times:
- • request sent:reply received: T 0 T 1
- Assume network delays are symmetric server
client^ request T 0 replyT 1 time
Tserver
Page 26
Cristian’s algorithm
Client sets time to:
server
client^ request T 0 replyT 1 time
Tserver
= estimated overhead in each direction
Page 27
Error bounds
If minimum message transit time (Tmin) is known:
Place bounds on accuracy of result
Page 28
Error bounds server
client^ request T 0 replyT 1 time
Tserver
Earliest time^ Tmin^ Tmin
message arrives Latest time message leaves
range = T 1 - T 0 - 2Tmin
accuracy of result =
Page 29
Cristian’s algorithm: example
- • Send request at 5:08:15.100 (Receive response at 5:08:15.900 ( T 0 ) T
- Response contains 5:09:25.300 ( Tserver)^1 )
- Elapsed time is 5:08:15.900 - 5:08:15.100 = 800 msec T 1 - T 0
- Best guess: timestamp was generated 400 msec ago
- Set time to 5:09:25.300 + 400 = 5:09.25.700 Tserver+ elapsed time Page 30
Cristian’s algorithm: example If best-case message time=200 msec server
client^ request T 0 replyT 1 time
Tserver
200 200
Error =
T T T (^01) s = 5:08:15.100= 5:08:15.900= 5:09:25: Tmin = 200msec
Page 37
Berkeley Algorithm: example
3. Send offset to each client
Page 38
Network Time Protocol, NTP
1991, 1992 Internet Standard, version 3: RFC 1305
Page 39
NTP Goals
- Enable clients across Internet to be accurately synchronized to UTC despite message delays
- Use statistical techniques to filter data and gauge quality of results
- Provide reliable service – Survive lengthy losses of connectivity
- – Redundant pathsRedundant servers
- Enable clients to synchronize frequently – offset effects of clock drift
- Provide protection against interference – Authenticate source of data Page 40
NTP servers
Arranged in strata – 1 st stratum: machines
connected directly to accurate time source
- (^2) synchronized from 1nd^ stratum: machinesst
- stratum machines…
SYNCHRONIZATION SUBNET
1 2 3 4
Page 41
NTP Synchronization Modes
Multicast mode – for high speed LANS
Procedure call mode^ –^ Lower accuracy but efficient
Symmetric mode^ –^ Similar to Cristian’s algorithm
- – Intended for master serversPair of servers exchange messages and retain data to improve synchronization over time All messages delivered unreliably with UDP Page 42
NTP messages
- Procedure call and symmetric mode – Messages exchanged in pairs
- NTP calculates: – Offset for each pair of messages
- Delay^ •^ Estimate of offset between two clocks
- Filter Dispersion^ •^ Transmit time between two messages
- • Estimate of errorBased on accuracy of server’s clock – quality of results and consistency of
- Use this data to find preferred server:^ network transit time
- lower stratum & lowest total dispersion
Page 43
NTP message structure
- Leap second indicator – Last minute has 59, 60, 61 seconds
- • Version numberMode (symmetric, unicast, broadcast)
- • Stratum (1=primary reference, 2Poll interval -15)
- Maximum interval between 2 successive messages, nearest power of 2
- Precision of local clock – Nearest power of 2 Page 44
NTP message structure
- Root delay – Total roundtrip delay to primary source
- Root dispersion^ –^ (16 bits seconds, 16 bits decimal)
- Reference clock ID^ –^ Nominal error relative to primary source
- Atomic, NIST dial system, GOES, GPS, …-up, radio, LORAN-C navigation
- Reference timestamp – Time at which clock was last set (64 bit)
- Authenticator (key ID, digest) – Signature (ignored in SNTP)
Page 45
NTP message structure
- T – 1 : originate timestampTime request departed client (client’s time)
- T – 2 : receive timestampTime request arrived at server (server’s time)
- T – 3 : transmit timestampTime request left server (server’s time)
Page 46
NTP’s validation tests
- Timestamp provided ≠ last timestamp received – duplicate message?
- Originating timestamp in message consistent with sent data
- Timestamp within range?^ –^ Messages arriving in order?
- • Originating and received timestamps ≠ 0?Authentication disabled? Else authenticate
- • Peer clock is synchronized?Don’t sync with clock of higher stratum #
- Reasonable data for delay & dispersion
Page 47
SNTP
Simple Network Time Protocol – Based on Unicast mode of NTP
- – Subset of NTP, not new protocolOperates in multicast or procedure call mode
- Recommended for environments where server is root node and client is leaf of synchronization
- subnetRoot delay, root dispersion, reference timestamp ignored
RFC 2030, October 1996
Page 48
SNTP
Roundtrip delay: d = (T 4 - T 1 ) - (T 2 - T 3 )
server
client^ request T 1 reply time
T 2
T 4
T 3
Time offset:
