520 likes | 661 Views
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:
E N D
End-To-End Scheduling Distributed Systems Seminar, Spring 2003 Angelo Corsaro & Venkita Subramonian Department of Computer Science Washington University
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
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”
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
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
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
Bottleneck Processor Example
Bottleneck Processor Example
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
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
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
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
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
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
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
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
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
Phase Modification Protocol - Analysis • Periodic Timer interrupt to release subtasks • Centralized clock or strict clock synchronization • Task overruns could cause Precedence constraint violations
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
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
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
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
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
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
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