Upload
alice-shepherd
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
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
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
Example
Removing Idle Time
Arbitrary Task Sets
Algorithms
Example
Example
Bottleneck Processor
Example
Bottleneck Processor
PART II
Synchronization Protocolsin
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
P1 P2
(4,2)T1
(6,2)T2,1
(6,2)T2,2
(6,3)T3
Ti,j – jth subtask of task Ti
(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
T1
T2,1
T2,2
T3
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
Phase of T3
T3 misses
deadline
P1 P2
(4,2)T1
(6,2)T2,1
(6,2)T2,2
(6,3)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 T1,2 T1,3
Actual response time
Estimated worst case response time
Phase of T1,2 Phase
of T1,3
p1
p1
p1
Phase Modification Protocol Illustrated (2/2)
On P1
On P2
T1
T2,1
T2,2
T3
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
Phase of T3
P1 P2
(4,2)T1
(6,2)T2,1
(6,2)T2,2
(6,3)T3
Phase of T2,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)
T1,1
T1,2
T1,1 T1,2 T1,3
Actual response time
Estimated worst case response time
p1
Overrun ∆
p1 + ∆
Modified PM Protocol Illustrated (2/2)
On P1
On P2
T1
T2,1
T2,2
T3
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
Phase of T3
P1 P2
(4,2)T1
(6,2)T2,1
(6,2)T2,2
(6,3)T3
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 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
1
1,
in
kkiR
in
kkiR
1,
+ 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
Release Guard Protocol Illustrated
On P1
On P2
T1
T2,1
T2,2
T3
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
2 4 6 8 10 12
Phase of T3
P1 P2
(4,2)T1
(6,2)T2,1
(6,2)T2,2
(6,3)T3
g1,2 = 4+6=10 g1,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
Ri,k is the response time of the kth subtask of Ti
ni is the number of subtasks for the task Ti
in
kkiR
1,
Lower bound on EER less than that of MPM If there are idle times Results in lower average EER
Comparison of Protocols
DS PM MPM RG
Implementation complexity
synch interrupts
Timer interrupts
clock synchronization
Synch & timer interrupts
Synch & timer interrupts
Run-time overhead
Average EER
Estimated worst case EER
Inherently missed deadlines
Yes No
Classification of Protocols
SynchronizationProtocols
Without execution control
With execution control
DS PM
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