End to end scheduling
This presentation is the property of its rightful owner.
Sponsored Links
1 / 52

End-To-End Scheduling PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on
  • Presentation posted in: General

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:

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


End to end scheduling

End-To-End Scheduling

Distributed Systems Seminar, Spring 2003

Angelo Corsaro & Venkita Subramonian

Department of Computer Science

Washington University


End to end scheduling

Prolog


Distributed real time systems

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

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”


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

Examples


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

Notice That…

Also Applies to Single Processor

We can avoid to consider multiple

flow-shop at the same time


End to end scheduling

PART I


System model

System Model


The flow shop

The Flow Shop


The flow shop1

The Flow Shop


Task models general results

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


The flow shop with recurrence

The Flow Shop with Recurrence


Visit graph

Visit Graph


Periodic flow shop

Periodic Flow-Shop


Scheduling algorithms for flow shop

Scheduling Algorithms for Flow-Shop


Identical length task sets

Identical-Length Task Sets


Algorithm

Algorithm


Optimality

Optimality


Homogeneous tasks sets

Homogeneous Tasks Sets


Algorithm1

Algorithm


Optimality1

Optimality


Example

Example


Example1

Example


Removing idle time

Removing Idle Time


Arbitrary task sets

Arbitrary Task Sets


Algorithms

Algorithms


Example2

Example


Example3

Bottleneck Processor

Example


Example4

Bottleneck Processor

Example


End to end scheduling

PART II


Synchronization protocols in end to end scheduling

Synchronization Protocolsin End-To-End Scheduling


Scope

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

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

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

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

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

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

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

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


Phase modification protocol illustrated 2 2

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

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

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


Modified pm protocol illustrated 2 2

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

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

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

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

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


Comparison of protocols

Comparison of Protocols


Classification of protocols

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


End to end scheduling

Epilogue


Concluding remarks

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

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


  • Login