1 / 71

Time Synchronization Chapter 9

Time Synchronization Chapter 9. TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A A A A. Rating. Area maturity Practical importance Theoretical importance. First steps Text book.

donnan
Download Presentation

Time Synchronization Chapter 9

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Time SynchronizationChapter 9 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAAA

  2. Rating • Area maturity • Practical importance • Theoretical importance First steps Text book No apps Mission critical Not really Must have

  3. Overview • Motivation • Clock Sources • Reference-Broadcast Synchronization (RBS) • Time-sync Protocol for Sensor Networks (TPSN) • Gradient Clock Synchronization

  4. 2. Time Synchronization in Distributed Systems

  5. Assumptions • Process can perform three kinds of atomic actions/events • Local computation • Send a single message to a single process • Receive a single message from a single process • Communication model • Point-to-point • Error-free, infinite buffer • Potentially out of order

  6. Motivation • Many protocols need to impose an ordering among events • If two players open the same treasure chest “almost” at the same time, who should get the treasure? • Physical clocks: • Seems to completely solve the problem • But what about theory of relativity? • Even without theory of relativity – efficiency problems

  7. Physical Clock Synchronization The relation between clock time and UTC when clocks tick at different rates.

  8. Types of Synchronization External Synchronization : Keep as close to UTC as possible Internal Synchronization : Mutual synchronization is important Phase Synchronization Types of clocks Unbounded 0, 1, 2, 3, . . . Bounded 0,1, 2, . . . M-1, 0, 1, . . . Classification Unbounded clocks are not realistic, but are easier to deal with in algorithms. Real clocks are always bounded.

  9. Drift rate  : Max rate two clocks can differ, < 10^-6 for Xtal clocks Clock skew  : Max. Allowed drift Resynchronization interval R : Depends on clock skew Challenges (Drift is unavoidable) Accounting for propagation delay Accounting for processing delay Faulty clocks Terminology

  10. A simple averaging algorithm Assume n clocks, at most t are faulty Step 1. Read every clock in the system. Step 2. Discard outliers and substitute them by the value of the local clock. Step 3. Update the clock using the average of these values. Internal synchronization Some clocks may be faulty. Exhibits 2-faced behavior

  11. Tiered architecture Broadcast mode - least accurate Procedure call - medium accuracy Peer-to-peer mode - upper level servers use this for max accuracy Network Time Protocol (NTP) Time server Level 0 Level 1 Level 1 Level 1 Level 2 Level 2 Level 2 The tree can reconfigure itself if some node fails.

  12. Let Q’s time be ahead of P’s time by . Then T2 = T1 + TPQ + T4 = T3 + TQP - y = TPQ + TQP = T2 +T4 -T1 -T3 (RTT)  = (T2 -T4 -T1 +T3) / 2 - (TPQ -TQP) / 2 P2P mode of NTP T2 T3 Q P T1 T4 x Between y/2 and -y/2 So, x- y/2 ≤  ≤ x+ y Ping several times, and obtain the smallest value of y. Use it to calculate 

  13. Cristian’s Algorithm • 1. Client gets data from a time server. • 2. It computes the round trip time (RTT), and compensates for this • delay while adjusting its own clock

  14. Berkeley Time Protocol (FromTanenbaum 2007) a) The timedaemon asks all the other machines for their clockvalues. b) The machines answer The time daemon tells everyone how to adjust their clock.

  15. Software “Clocks” • Software “clocks” can incur much lower overhead than maintaining (sufficiently accurate) physical clocks • Allows a protocol to infer ordering among events • Goal of software “clocks”: Capture event ordering that are visible to users • But what orderings are visible to users without physical clocks?

  16. Visible Ordering to Users • A  B (process order) • B  C (send-receive order) • A  C (transitivity) A ? D B ? D C ? D B A user1 (process1) C user2 (process2) user3 (process3) D

  17. “Happened-Before” Relation • “Happened-before” relation captures the ordering that is visible to users when there is no physical clock • A partial order among events • Process-order, send-receive order, transitivity • First introduced by Lamport – Considered to be the first fundamental result in distributed computing • Goal of software “clock” is to capture the above “happened-before” relation. Formally, a logical clock C is a map from the set of events E to N (the set of natural numbers) with the following constraint:

  18. 1: Logical Clocks • Each event has a single integer as its logical clock value • Each process has a local counter C • Increment C at each “local computation” and “send” event • When sending a message, logical clock value V is attached to the message. At each “receive” event, C = max(C, V) + 1 3 = max(1,2)+1 4 = max(3,3)+1 1 2 3 4 user1 (process1) 1 4 5 3 user2 (process2) 1 2 5 user3 (process3)

  19. Logical Clock Properties • Theorem: • Event s happens before t  the logical clock value of s is smaller than the logical clock value of t. • The reverse may not be true 1 2 3 4 user1 (process1) 1 4 5 3 user2 (process2) 1 2 5 user3 (process3)

  20. Lamport’s Logical Clock Algorithm

  21. 2: Vector Clocks • Logical clock: • Vector clock: • Event s happens before event t  the vector clock value of s is “smaller” than the vector clock value of t. • Each event has a vector of n integers as its vector clock value • v1 = v2 if all n fields same • v1  v2 if every field in v1 is less than or equal to the corresponding field in v2 • v1 < v2 if v1  v2 and v1 ≠ v2 Relation “<“ here is not a total order

  22. Vector Clock Protocol • Each process i has a local vector C • Increment C[i] at each “local computation” and “send” event • When sending a message, vector clock value V is attached to the message. At each “receive” event, C = pairwise-max(C, V); C[i]++; C = (0,1,0), V = (0,0,2) pairwise-max(C, V) = (0,1,2) (1,0,0) (2,0,0) (3,0,0) user1 (process1) (0,2,2) (2,3,2) (0,1,0) user2 (process2) (0,0,2) (2,3,3) (0,0,1) user3 (process3)

  23. Vector Clock Properties • Event s happens before t  vector clock value of s < vector clock value of t: There must be a chain from s to t • Event s happens before t  vector clock value of s < vector clock value of t • If s and t on same process, done • If s is on p and t is on q, let VS be s’s vector clock and VT be t’s • VS < VT  VS[p] ≤ VT[p]  Must be a sequence of message from p to q after s and before t s p t q

  24. Example Application of Vector Clock • Each user has an order placed by a customer • Want all users to know all orders • Each order has a vector clock value I have seen all orders whose vector clock is smaller than (2,3,2): I can avoid linear search for existence testing D1, (1,0,0) (2,0,0) (3,0,0) user1 (process1) (0,2,2) D1 (2,3,2) D2, (0,1,0) user2 (process2) D1, D2, D3 D3 D3, (0,0,1) (2,3,3) (0,0,2) user3 (process3)

  25. Vector Clock Algorithm

  26. A sample execution of the vector clock algorithm

  27. Summary • Goal : Define “time” in a distributed system • Logical clock • “happened before”  smaller clock value • Vector clock • “happened before”  smaller clock value • Matrix clock • Gives a process knowledge about what other processes know

  28. Motivation • Time synchronization is essential for many applications • Coordination of wake-up and sleeping times (energy efficiency) • TDMA schedules • Ordering of collected sensor data/events • Co-operation of multiple sensor nodes • Estimation of position information (e.g. shooter detection) • Goals of clock synchronization • Compensate offset between clocks • Compensate drift between clocks

  29. Properties of Synchronization Algorithms • External versus internal synchronization • External sync: Nodes synchronize with an external clock source (UTC) • Internal sync: Nodes synchronize to a common time • to a leader, to an averaged time, or to anything else • Instant versus periodic synchronization • Periodic synchronization required to compensate clock drift • A-priori versus a-posteriori • A-posteriori clock synchronization triggered by an event • Local versus global synchronization

  30. Clock Sources • Radio Clock Signal: • Clock signal from a reference source (atomic clock) is transmitted over a longwave radio signal • DCF77 station near Frankfurt, Germany transmits at 77.5 kHz with a transmission range of up to 2000 km • Accuracy limited by the distance to the sender, Frankfurt-Zurich is about 1ms. • Special antenna/receiver hardware required • Global Positioning System (GPS): • Satellites continuously transmit own position and time code • Line of sight between satellite and receiver required • Special antenna/receiver hardware required

  31. Clock Devices in Sensor Nodes • Structure • External oscillator with a nominal frequency (e.g. 32 kHz) • Counter register which is incremented with oscillator pulses • Works also when CPU is in sleep state • Accuracy • Clock drift: random deviation from the nominal rate dependent on power supply, temperature, etc. • E.g. TinyNodes have a maximum drift of 30-50 ppm at room temperature This is a drift of up to 50 μs per second or 0.18s per hour Oscillator

  32. Sender/Receiver Synchronization • Round-Trip Time (RTT) based synchronization • Receiver synchronizes to the sender‘s clock • Propagation delay  and clock offset  can be calculated

  33. Disturbing Influences on Packet Latency • Influences • Sending Time S (up to 100ms) • Medium Access Time A (up to 500ms) • Transmission Time T (tens of milliseconds, depending on size) • Propagation Time PA,B (microseconds, depending on distance) • Reception Time R (up to 100ms) • Asymmetric packet delays due to non-determinism • Solution: timestamp packets at MAC Layer S T A Timestamp TA R PA,B Timestamp TB Critical path

  34. Reference-Broadcast Synchronization (RBS) • A sender synchronizes a set of receivers with one another • Point of reference: beacon’s arrival time A S B • Only sensitive to the difference in propagation and reception time • Time stamping at the interrupt time when a beacon is received • After a beacon is sent, all receivers exchange their reception times to calculate their clock offset • Post-synchronization possible • Least-square linear regression to tackle clock drifts

  35. 0 1 1 1 2 2 2 2 Time-sync Protocol for Sensor Networks (TPSN) • Traditional sender-receiver synchronization (RTT-based) • Initialization phase: Breadth-first-search flooding • Root node at level 0 sends out a level discovery packet • Receiving nodes which have not yet an assigned level set their levelto +1 and start a random timer • After the timer is expired, a new level discovery packet will be sent • When a new node is deployed, it sends out a level request packet after a random timeout

  36. Time-sync Protocol for Sensor Networks (TPSN) • Synchronization phase • Root node issues a time sync packet which triggers a random timer at all level 1 nodes • After the timer is expired, the node asks its parent for synchronization using a synchronization pulse • The parent node answers with an acknowledgement • Thus, the requesting node knows the round trip time and can calculate its clock offset • Child nodes receiving a synchronization pulse also start a random timer themselves to trigger their own synchronization 0 Time Sync 1 B ACK Sync pulse 1 2 A 2 2

  37. 0 1 B 1 2 A 2 2 Time-sync Protocol for Sensor Networks (TPSN) • Time stamping packets at the MAC layer • In contrast to RBS, the signal propagation time might be negligible • Authors claim that it is “about two times” better than RBS • Again, clock drifts are taken into account using periodical synchronization messages • Problem: What happens in a non-tree topology (e.g. ring)?!? • Two neighbors may have exceptionally bad synchronization

  38. 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 Theoretical Bounds for Clock Synchronization • Network Model: • Each node i has a local clock Li(t) • Network with n nodes, diameter D. • Reliable point-to-point communication with minimal delay µ • Jitter ε is the uncertainty in message delay • Two neighboring nodes u, v cannot distinguish whether message is faster from u to v and slower from v to u, or vice versa. Hence clocks of neighboring nodes can be up to  off. • Hence, two nodes at distance D may have clocks which are D off. • This can be achieved by a simple flooding algorithm: Whenever a node receives a new minimum value, it sets its clock to the new value and forwards its new clock value to all its neighbors. v v µ +  µ µ µ +  u u

  39. Gradient Clock Synchronization • Global property: Minimize clock skew between any two nodes • Local (gradient) property: Small clock skew between two nodes if the distance between the nodes is small. • Clock should not be allowed to jump backwards • You don’t want new events to be registered earlier than older events. • Example: Ring topology Root node 0 1 1 Small clock skew 2 2 3 3 4 Large clock skew

  40. Trivial Solution: Let t = 0 at all nodes and times • Global property: Minimize clock skew between any two nodes • Local (gradient) property: Small clock skew between two nodes if the distance between the nodes is small. • Clock should not be allowed to jump backwards • To prevent trivial solution, we need a fourth constraint: • Clock should always to move forward. • Sometimes faster, sometimes slower is OK. • But there should be a minimum and a maximum speed.

  41. Gradient Clock Synchronization • Model • Each node has a hardware clock Hi(∙) with a clock rate where 0 < L < U and U≥ 1 • The time of node i at time t is • Each node has a logical clock Li(∙) which increases at the rate of Hi(∙) • Employ a synchronization algorithm A to update the local clock with fresh clock values from neighboring nodes (clock cannot run backwards) • Nodes inform their neighboring nodes when local clock is updated Time is 152 Time is 142 Time is 140 Time is 150 ???

  42. Ad hoc & sensor networs - Ch 8: Time Synchronization Goals of this chaper • Understand the importance of time synchronization in WSNs • Understand typical strategies for time synchronization and how they are applied in WSNs

  43. Ad hoc & sensor networs - Ch 8: Time Synchronization Overview • The time synchronization problem • Protocols based on sender/receiver synchronization • Protocols based on receiver/receiver synchronization • Summary

  44. Ad hoc & sensor networs - Ch 8: Time Synchronization Overview • The time synchronization problem • Protocols based on sender/receiver synchronization • Protocols based on receiver/receiver synchronization • Summary

  45. Ad hoc & sensor networs - Ch 8: Time Synchronization Goal: estimate angle of arrival of a very distant sound event using an array of acoustic sensors From the figure, q can be estimated when x and d are known: d is known a priori, x must be estimated from differences in time of arrival x = C Dt where C is the speed of sound For d=1 m and Dt=0.001 we get q = 0.336 radians When Dt is estimated with 500 ms error, the q estimates can vary between 0.166 and 0.518 Morale: a seemingly small error in time synch can lead to significantly different angle estimates Example

  46. Ad hoc & sensor networs - Ch 8: Time Synchronization The role of time in WSNs • Time synchronization algorithms can be used to better synchronize clocks of sensor nodes • Time synchronization is needed for WSN applications and protocols: • Applications: AOA estimation, beamforming • Protocols: TDMA, protocols with coordinated wakeup, ... • Distributed debugging: timestamping of distributed events is needed to figure out their correct order of appearance • WSN have a direct coupling to the physical world, hence their notion of time should be related to physical time: • physical time = wall clock time, real-time, i.e. one second of a WSN clock should be close to one second of real time • Commonly agreed time scale for real time is UTC, generated from atomic clocks and modified by insertion of leap seconds to keep in synch with astronomical timescales (one rotation of earth) • Other concept: logical time (Lamport), where only the relative ordering of events counts but not their relation to real time

  47. Ad hoc & sensor networs - Ch 8: Time Synchronization Clocks in WSN nodes • Often, a hardware clock is present: • An oscillator generates pulses at a fixed nominal frequency • A counter register is incremented after a fixed number of pulses • Only register content is available to software • Register change rate gives achievable time resolution • Node i’s register value at real time t is Hi(t) • Convention: small letters (like t, t’) denote real physical times, capital letters denote timestamps or anything else visible to nodes • A (node-local) software clock is usually derived as follows: • Li(t) = qi Hi(t) + fi (not considering overruns of the counter-register) • qi is the (drift) rate, fi the phase shift • Time synchronization algorithms modify qi and fi, but not the counter register

  48. Ad hoc & sensor networs - Ch 8: Time Synchronization Synchronization accuracy / agreement • External synchronization: • synchronization with external real time scale like UTC • Nodes i=1, ..., n are accurate at time t within bound d when |Li(t) – t|<d for all i • Hence, at least one node must have access to the external time scale • Internal synchronization • No external timescale, nodes must agree on common time • Nodes i=1, ..., n agree on time within bound d when |Li(t) – Lj(t)|<d for all i,j

  49. Ad hoc & sensor networs - Ch 8: Time Synchronization Sources of inaccuracies • Nodes are switched on at random times, phases θi hence can be random • Actual oscillators have random deviations from nominal frequency (drift, skew) • Deviations are specified in ppm (pulses per million), the ppm value counts the additional pulses or lost pulses over the time of one million pulses at nominal rate • The cheaper the oscillators, the larger the average deviation • For sensor nodes values between 1 ppm (one second every 11 days) and 100 ppm (one second every 2.8 hours) are assumed, Berkeley motes have an average drift of 40 ppm • Oscillator frequency depends on time (oscillator aging) and environment (temperature, pressure, supply voltage, ...) • Especially the time-dependent drift rates call for frequent re-synchronization, as one-time synchronization is not sufficient • However, stability over tens of minutes is often a reasonable assumption

  50. Ad hoc & sensor networs - Ch 8: Time Synchronization General properties of time synchronization algorithms • Physical time vs. logical time • External vs. internal synchronization • Global vs. local algorithms • Keep all nodes of a WSN synchronized or only a local neighbourhood? • Absolute vs. relative time • Hardware vs. software-based mechanisms • A GPS receiver would be a hardware solution, but often too heavyweight/costly/energy-consuming in WSN nodes, and in addition a line-of-sight to at least four satellites is required • A-priori vs. a-posteriori synchronization • Is time synchronization achieved before or after an interesting event?  Post-facto synchronization • Deterministic vs. stochastic precision bounds • Local clock update discipline • Should backward jumps of local clocks be avoided? (Users of make say yes here ....) • Avoid sudden jumps?

More Related