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