End-To-End Scheduling Angelo Corsaro & Venkita Subramonian Department of Computer Science Washington University Distributed Systems Seminar, Spring 2003

Prolog

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

Narrowing the Scope  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  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”

Examples  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

Notice That…  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 Also Applies to Single Processor We can avoid to consider multiple flow-shop at the same time

PART I

System Model

The Flow Shop

Task Models & General Results  A task is preemptable if 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.

The Flow Shop with Recurrence

Visit Graph

Periodic Flow-Shop

Scheduling Algorithms for Flow-Shop

Identical-Length Task Sets

Algorithm

Optimality

Homogeneous Tasks Sets

Algorithm

Optimality

Example

Removing Idle Time

Arbitrary Task Sets

Algorithms

Example

Bottleneck Processor

Example Bottleneck Processor

PART II

Synchronization Protocols in End-To-End Scheduling

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 P1P2 (4,2) T1T1 (6,2) T 2,1 (6,2) T 2,2 (6,3) T3T3 T i,j – j th subtask of task T i (period,execution time) Period = relative deadline of parent task Task T3 has a phase of 4 time units

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

Direct Synchronization Illustrated On P1 On P2 T1T1 T 2,1 T 2,2 T3T Phase of T 3 T 3 misses deadline P1P2 (4,2) T1T1 (6,2) T 2,1 (6,2) T 2,2 (6,3) T3T3

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) T 1,1 T 1,2 T 1,3 T 1,1 T 1,2 T 1,3 Actual response time Estimated worst case response time Phase of T 1,2 Phase of T 1,3 p1p1 p1p1 p1p1

Phase Modification Protocol Illustrated (2/2) On P1 On P2 T1T1 T 2,1 T 2,2 T3T Phase of T 3 P1P2 (4,2) T1T1 (6,2) T 2,1 (6,2) T 2,2 (6,3) T3T3 Phase of T 2,2

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) T 1,1 T 1,2 T 1,1 T 1,2 T 1,3 Actual response time Estimated worst case response time p1p1 Overrun ∆ p 1 + ∆

Modified PM Protocol Illustrated (2/2) On P1 On P2 T1T1 T 2,1 T 2,2 T3T Phase of T 3 P1P2 (4,2) T1T1 (6,2) T 2,1 (6,2) T 2,2 (6,3) T3T3 Synch signal delayed

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 T i R i,k is the response time of the k th subtask of T i n i is the number of subtasks for the task T i  Lower bound on End-to-End Response time of task T i + Actual Response time of n i th 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

Release Guard Protocol Illustrated On P1 On P2 T1T1 T 2,1 T 2,2 T3T Phase of T 3 P1P2 (4,2) T1T1 (6,2) T 2,1 (6,2) T 2,2 (6,3) T3T3 g 1,2 = 4+6=10g 1,2 = 9 Idle time detected

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 R i,k is the response time of the k th subtask of T i n i is the number of subtasks for the task T i  Lower bound on EER less than that of MPM  If there are idle times  Results in lower average EER

Comparison of Protocols DSPMMPMRG Implementation complexity synch interrupts Timer interrupts clock synchronization Synch & timer interrupts Run-time overhead Average EER Estimated worst case EER Inherently missed deadlines YesNo

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

Epilogue

Concluding Remarks  Flow-Shop can be used to model a series of real-world systems  The Flow-Shop approach assumes that the task set is fully characterized i.e. it is amenable to off-line analysis, but it’s not ideal for on-line analysis  Optimal algorithms exists for some easy cases, yet some classes of real systems (e.g. some control systems, real-time networks) usually fits these cases

References  “End-To-End Scheduling to meet deadlines in Distributed Systems“, Riccardo Bettati, Jane Liu  Synchronization Protocols in Distributed Real-Time Systems, Jun Sun and Jane Liu, ICDCS ’96  Fixed Priority End-to-End Scheduling in Distributed Real-Time Systems, Jun Sun, PhD Thesis