end to end scheduling
Download
Skip this Video
Download Presentation
End-To-End Scheduling

Loading in 2 Seconds...

play fullscreen
1 / 52

End-To-End Scheduling - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

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:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' End-To-End Scheduling' - jens


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

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

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

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

ad