1 / 35

Work in Progress

Why, Where and How to Use the  - Model Josef Widder Embedded Computing Systems Group widder@ecs.tuwien.ac.at INRIA Rocquencourt, March 10, 2004. Work in Progress. Motivation Ideas Our Approach First Results in certain types of networks. Overview.

brygid
Download Presentation

Work in Progress

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. Why, Where and How toUse the  - ModelJosef WidderEmbedded Computing Systems Groupwidder@ecs.tuwien.ac.atINRIA Rocquencourt, March 10, 2004

  2. Work in Progress • Motivation • Ideas • Our Approach • First Results in certain types of networks

  3. Overview • Why: Because classic results are straight forward but have drawbacks • Where: A glance at synchrony in real networks • How: Transfer of algorithm to real systems

  4. Consensus • Dwork, Lynch, Stockmeyer 88 • Chandra, Toueg 96 • There exist algorithmic solutions if  holds •  is the upper bound on end-to-end message delays • What remains: Show that your system ensures

  5. Diverse assumptions on  •  is known/unknown •  hold always/from some time one/sufficiently long •  holds for all/some (FD) msgs … [DLS88] / [CT96] •  holds eventually somewhere … [ADFT03] These are weak assumptions, still  is in there

  6. By the way ... upper bounds look like this

  7. Upper bounds do not look like this • Let’s assume = 8s and test it for a week • Approaches like [MF02] • delay of a protocol is 5 • delay should be at most 5s • let’s define  = 1s

  8. Can upper bounds be derived properly ? • Guarantees are (NP) hard to derive (scheduling, queuing) • problem must be simplified • simplification leads to incomplete guarantees

  9. What do I have to analyze to ensure  • local delays sender (processor load, task preemption, blocking factors) • outbound queues • net contention • inbound queues • local delays receiver (processor load, task preemption, blocking factors) This is hard, yet only delivers  at some probability.

  10. Assumption Coverage The probability that our assumptions hold during operation Our Starting Point: We can improve coverage by means of system models

  11. The Model (t) ... Upper envelope of message delays at time t (t) ... Lower envelope of message delays at time t Since (t) is unbounded, local HW timers cannot timeout messages  time(r) free algorithms

  12. Described Behavior (rough sketch) end-to-end delays   t

  13. Coverage of  C < 1 C = 1

  14. Coverage of the  - Model How large is states(  ) ? And why is this interesting anyway ?

  15. Consensus in Real Networks From FLP follows: Any solution to Consensus on a real network is a probabilistic solution … not even talking about coverage of fault models

  16. How large is coverage improvement ? • Coverage cannot be worse than in  assumption • if relation of  and  exists, improvement is large. • But even in networks without relation of  and  (if such exist?) • If by chance there exists just one case where  holds while  does not, coverage is improved

  17. Performance termination times often look like hence: How large is  ? • Step 1  timing uncertainty of networks • Step 2  establish , , and  on given networks, for a given system model for given algorithms

  18. Benchmark for Timing Uncertainty in clock synchronization the best precision one can reach is  =  -  [LL84] …  (1-1/n) comparison of two approaches in Ethernet • clock sync • their results • conclude where to use our model

  19. Clock Sync in Ethernets • NTP [Mills] • Accuracy of ~1ms • SynUTC [http://www.auto.tuwien.ac.at/Projects/SynUTC/papers.html] • Accuracy of ~100ns Why is there a difference of 4 orders of magnitude?

  20. Wherefrom comes the difference ? • NTP runs at application level • SynUTC runs low level • current clock value is directly copied onto the bus • upon message receipt, receiver’s clock value is written in the received message as well • interval based clock sync algorithms [SS03]

  21. Conclusions from this comparison • low level clock sync • high level applications use tightly synchronized clocks • But how does this help us in solving Consensus? • Fast Failure Detector Approach [HLL02] ([CT96]: just FD messages must satisfy timing assumptions)

  22. Fast Failure Detectors • low level failure detection • high priority FD messages … n = 16…1024

  23. Performance (after Step 1) • Timing uncertainty differs in same network depending on the layer the algorithm runs in •  should be reasonable good in lower levels • Step 2: establish , , and  on given networks, for a given system model running given algorithms

  24. Algorithms in Networks • Leader Election • Token Circulation (1x) • 1.  2. end-to-end delays , 

  25. Theoretical Analysis • Leader Election • bc(leader) =  ... wc(leader) =  • one Token Circulation • bc(token) = 3 ... wc(token) = 3 • Leader  Token • bc(comb) = 4 ... wc(comb) = 4

  26. Establish Time Bounds • end-to-end delays • from decision to send a message until receivermakes its decision •  = ts + trans + tr •  = 2ts + trans + 2tr … message arrival laws rate of transmission to one p

  27. Termination Times Leader Election Token Circulation

  28. ... by adding ... by examination Termination Times (2) Leader Election  Token Round

  29. Conclusions of Step 2a • during operation ,  do not only depend on the system • algorithms must be accounted as well • how many messages are sent  network load • this was a toy example BUT

  30. Deterministic Ethernet … CSMA/DCR • bus  only one message on the medium at a time • deterministic collision resolution • upper bound on physical message transmission (i.e. trans not the end-to-end delay) • if a station wants to send a message at t1 and sends it at t2 (collision) then every station can at most send one message between t1 and t2

  31.  =  -  … is only relevant for one broadcast in fact the time difference for receiving n - f msgs Hot: First Results in Deterministic Ethernet

  32. in deterministic Ethernet: but we require f+1 msgs: First Results (2) ... how many messages transferred during any message is in transit

  33. First Results in Deterministic Ethernet (3) • n = 1024 and f = 511 … crash faults, hence n > 2f • derive properties which are equivalent to   2 in the system model • results apply in TDMA networks as well (due to inefficiency of the bus arbitration  might be even smaller)

  34. Conclusions •  - Model reaches higher assumption coverage • small timing uncertainty in lower network levels • , , , and  are related to • real network • algorithm •  remains within reasonable bounds

  35. anks !

More Related