1 / 52

End-To-End Scheduling

End-To-End Scheduling. Distributed Systems Seminar, Spring 2003. Angelo Corsaro & Venkita Subramonian Department of Computer Science Washington University. Prolog. Distributed Real-Time Systems. The key characteristics of Distributed Real-Time Systems (DRTS) are:

jens
Télécharger la présentation

End-To-End Scheduling

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. End-To-End Scheduling Distributed Systems Seminar, Spring 2003 Angelo Corsaro & Venkita Subramonian Department of Computer Science Washington University

  2. Prolog

  3. Distributed Real-Time Systems • The key characteristics of Distributed Real-Time Systems (DRTS) are: • Tasks in the system require service from several “processors” (Resource are Distributed) • The correctness of a Task depends on its timely completion (Tasks are Real-Time) • Usually a task in a DRTS can be thought as a set of sub-tasks, where each sub-task represent the work needed from a given resource • Execution on a processor • Transmission over a link • etc. • A DRTS Task is characterized by • End-to-End deadline: Time at which the last sub-task has to complete • End-to-End release time: Time after which the first sub-task can start its execution

  4. The general case of a Distributed Real-Time System is too hard There are some sub-classes which impose some restriction on the general case and are easier to reason about An interesting sub-class is that of DRTS which can be characterized as Flow-Shop or Generalized Flow-Shop problems The Flow-Shop is one of the abstraction used to model Manufacturing Systems like the following Narrowing the Scope • A key characteristic of the flow-shop is that all task execute on all the “processors” on the same order • Traditional Flow-Shop problems don’t have to cope with timeliness, but simply try to minimize the completion time • If a DRTS is modeled as a flow shop, each node and each communication link can be modeled as a “processor”

  5. The flow-shop model is a good abstraction to represent several classes of DRTS Examples are Distributed Control System Multimedia Systems Multi-Hop real-time networks Interconnected Field-Buses etc.etc In a video server the sub-task of each stream could be modeled as: Access and Delivery Transmission Acquisition and Display Further decomposition is possible Examples

  6. End-to-End timing constraints are not necessarily limited to distributed systems For instance, task accessing a non-sharable resource can be thought as temporarily “executing” on that resource This type of task can be characterized as a chain of three sub-tasks with an end-to-end deadline A system may contains many classes of tasks Tasks in each class execute on different processors on the same order Tasks in different classes execute on different processors on different order Multiple classes can be scheduled by statically partitioning the resources so to create virtual processors Warning: Static partitioning might lead to poor utilization Notice That… Also Applies to Single Processor We can avoid to consider multiple flow-shop at the same time

  7. PART I

  8. System Model

  9. The Flow Shop

  10. The Flow Shop

  11. A task is preemptableif its execution can be interrupted and, at a later point in time, resumed A task is non-preemptable if its execution cannot be interrupted Schedulers that make use of the fact that a task is preemptable are called preemptive schedulers. Task Models & General Results

  12. The Flow Shop with Recurrence

  13. Visit Graph

  14. Periodic Flow-Shop

  15. Scheduling Algorithms for Flow-Shop

  16. Identical-Length Task Sets

  17. Algorithm

  18. Optimality

  19. Homogeneous Tasks Sets

  20. Algorithm

  21. Optimality

  22. Example

  23. Example

  24. Removing Idle Time

  25. Arbitrary Task Sets

  26. Algorithms

  27. Example

  28. Bottleneck Processor Example

  29. Bottleneck Processor Example

  30. PART II

  31. Synchronization Protocolsin End-To-End Scheduling

  32. Scope • Job-shop model • Each task needs to execute on a set of processors in a certain order • Each task may require a different order • Problems in End-to-End scheduling • Priority assignment • Assign fixed priorities to tasks so that the system is schedulable • Synchronization of tasks • Control the releases of subtask instances (non-first subtasks) • Schedulability analysis • For a given priority assignment and a given synchronization protocol, whether every instance of each task meets its deadline

  33. The Synchronization Problem • Given that • Priorities are assigned to subtasks in a task chain using some fixed priority assignment algorithm • How do we coordinate the release of subtasks in a task chain so that • Precedence constraints among subtasks are satisfied • subtask deadlines are met • end-to-end deadlines are met

  34. Synchronization Protocols • Direct Synchronization (DS) Protocol • Simple and straightforward • Phase Modification (PM) Protocol • Proposed by Bettati • Used by flow-shop tasks • Extension called Modified Phase Modification (MPM) Protocol • Release Guard Protocol • Proposed by Sun

  35. Synchronization Protocol - Example P1 P2 T1 (4,2) T2,2 (6,2) T2,1 (6,2) T3 (6,3) Ti,j – jth subtask of task Ti Task T3 has a phase of 4 time units (period,execution time) Period = relative deadline of parent task

  36. Direct Synchronization Protocol • Greedy strategy • On completion of subtask • A synchronization signal sent to the next processor • Successor subtask competes with other tasks/subtasks on the next processor

  37. P1 P2 2 2 2 2 4 4 4 4 6 6 6 6 8 8 8 8 10 10 10 10 12 12 12 12 T1 (4,2) T2,2 (6,2) T2,1 (6,2) T3 (6,3) Direct Synchronization Illustrated T1 T2,1 On P1 On P2 T2,2 T3 misses deadline Phase of T3 T3

  38. Phase Modification Protocol • Proposed by Bettati • Release subtasks periodically • According to the periods of their parent tasks • Each subtask given its own phase • Phase determined by subtask precedence constraints

  39. Phase Modification Protocol Illustrated (1/2) T1,1 T1,2 T1,3 T1,1 p1 T1,2 p1 T1,3 p1 Phase of T1,2 Phase of T1,3 Actual response time Estimated worst case response time

  40. P1 P2 2 2 2 2 4 4 4 4 6 6 6 6 8 8 8 8 10 10 10 10 12 12 12 12 T1 (4,2) T2,2 (6,2) T2,1 (6,2) T3 (6,3) Phase Modification Protocol Illustrated (2/2) T1 T2,1 On P1 On P2 Phase of T2,2 T2,2 Phase of T3 T3

  41. Phase Modification Protocol - Analysis • Periodic Timer interrupt to release subtasks • Centralized clock or strict clock synchronization • Task overruns could cause Precedence constraint violations

  42. Modified PM Protocol Illustrated (1/2) T1,1 T1,2 T1,3 T1,1 p1 Overrun ∆ T1,2 p1 + ∆ Actual response time Estimated worst case response time

  43. P1 P2 2 2 2 2 4 4 4 4 6 6 6 6 8 8 8 8 10 10 10 10 12 12 12 12 T1 (4,2) T2,2 (6,2) T2,1 (6,2) T3 (6,3) Modified PM Protocol Illustrated (2/2) T1 Synch signal delayed T2,1 On P1 On P2 T2,2 Phase of T3 T3

  44. Modified PM Protocol - Analysis • MPM protocol behavior the same as PM under ideal conditions • Ideal conditions – Clocks synchronized, no overrun • MPM protocol does not need clock synchronization • Precedence constraints preserved even in the case of overruns • Upper bound on End-to-End Response time of task Ti Ri,k is the response time of the kth subtask of Ti ni is the number of subtasks for the task Ti • Lower bound on End-to-End Response time of task Ti + Actual Response time of nith subtask • Lower bound high, hence high average EER time

  45. Release Guard Protocol • Proposed by Sun • A guard variable – release guard - associated with each subtask • Release guard used to control release of each subtask • Contains next release time of subtask • Synchronization signals just like MPM • Release guard updated • On getting synchronization signal • During idle time

  46. P1 P2 2 2 2 2 4 4 4 4 6 6 6 6 8 8 8 8 10 10 10 10 12 12 12 12 T1 (4,2) T2,2 (6,2) T2,1 (6,2) T3 (6,3) Release Guard Protocol Illustrated T1 T2,1 On P1 On P2 g1,2 = 4+6=10 g1,2 = 9 T2,2 Idle time detected Phase of T3 T3

  47. Release Guard Protocol - Analysis • Shares the same advantages as MPM • Upper bound on EER still the same as MPM • Since upper bound on release time enforced by release guard Ri,k is the response time of the kth subtask of Ti ni is the number of subtasks for the task Ti • Lower bound on EER less than that of MPM • If there are idle times • Results in lower average EER

  48. Comparison of Protocols

  49. Classification of Protocols Synchronization Protocols Without execution control With execution control DS PM MPM RG Task release controlled by predecessor processor by delaying the synch signal Task release controlled by same processor by using guard variables Phase modification

  50. Epilogue

More Related