Rate monotonic analysis
This presentation is the property of its rightful owner.
Sponsored Links
1 / 87

Rate Monotonic Analysis PowerPoint PPT Presentation


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

Rate Monotonic Analysis. Rob Oshana Southern Methodist University. Scheduling policies for real-time systems. Scheduling Policies in RT systems. Two general categories fixed or static scheduling policies dynamic scheduling policies

Download Presentation

Rate Monotonic Analysis

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


Rate monotonic analysis

Rate Monotonic Analysis

Rob Oshana

Southern Methodist University


Scheduling policies for real time systems

Scheduling policies for real-time systems


Scheduling policies in rt systems

Scheduling Policies in RT systems

  • Two general categories

    • fixed or static scheduling policies

    • dynamic scheduling policies

  • Many commercial RTOSs today support fixed priority scheduling policies

  • Fixed priority scheduling algorithms do not modify a job’s priority while the task is running


Scheduling policies in rt systems1

Scheduling Policies in RT systems

  • The task itself is allowed to modify its own priority for reasons

  • approach requires very little support code on the scheduler to implement this functionality

  • scheduler is fast and predictable with this approach

  • scheduling is mostly done off-line (before the system runs)


Scheduling policies in rt systems2

Scheduling Policies in RT systems

  • Requires system designer to know the task set a-priori (ahead of time)

    • not suitable for tasks that are created dynamically during run time

  • The priority of the task set must be determined beforehand and cannot change when the system runs unless the task itself changes its own priority


Scheduling policies in rt systems3

Scheduling Policies in RT systems

  • Dynamic scheduling algorithms allow a scheduler to modify a jobs priority based on one of several scheduling algorithms or policies

    • more complicated approach and requires more code in the scheduler to implement


Scheduling policies in rt systems4

Scheduling Policies in RT systems

  • leads to more overhead in managing a task set

  • scheduler must spend more time dynamically sorting through the system task set and prioritize tasks for execution based on the scheduling policy

  • leads to non-determinism which is not favorable, especially for hard real-time systems


Scheduling policies in rt systems5

Scheduling Policies in RT systems

  • Dynamic scheduling algorithms are on-line scheduling algorithms

    • scheduling policy is applied to the task set during the execution of the system

    • active task set changes dynamically as the system runs

    • priority of the tasks can also change dynamically


Examples

Examples

  • Static scheduling policies

    • rate monotonic scheduling

    • deadline monotonic scheduling

  • Dynamic scheduling policies

    • earliest deadline first

    • least slack scheduling


Rate monotonic scheduling

Rate Monotonic Scheduling

  • Optimal fixed priority policy

    • the higher the frequency (1/period) of a task, the higher is its priority

  • Approach can be implemented in any OS supporting the fixed priority preemptive scheme

  • Rate monotonic scheduling assumes the deadline of a periodic task is the same as its period


Deadline monotonic scheduling

Deadline Monotonic Scheduling

  • Generalization of the Rate-Monotonic scheduling policy

  • Deadline of a task is a fixed (relative) point in time from the beginning of the period

  • The shorter this (fixed) deadline, the higher the priority


Earliest deadline first

Earliest Deadline First

  • Dynamic priority preemptive policy

  • Deadline of a task instance is the absolute point in time by which the instance must complete

  • Task deadline is computed when the instance is created

  • OS scheduler picks the task with the earliest deadline to run

  • A task with an earlier deadline preempts a task with a later deadline


Least slack

Least Slack

  • Dynamic priority preemptive policy

  • Slack of a task instance is the absolute deadline minus the remaining execution time for the instance to complete

  • OS scheduler picks the task with the shortest slack to run first

  • Task with a smaller slack preempts a task with a larger slack

  • This approach maximizes the minimum lateness of tasks


More on dynamic policies

More on dynamic policies

  • Priority of a task can change from instance to instance or within the execution of an instance

  • Higher priority task preempts a lower priority task

  • Very few commercial RTOS support such policies

    • systems that are hard to analyze for real-time and determinism properties


Periodic tasks

Periodic tasks

  • Many systems are multi-rate systems

    • multiple tasks in the system running at different periodic rates

  • Muli-rate systems can be managed using non-preemptive as well as preemptive scheduling techniques

  • Non-preemptive techniques include using state machines as well as cyclic executives


Rate monotonic analysis

Examples of periodic tasks

  • Audio sampling in hardware

  • Audio sample processing

  • Video capture and processing

  • Feedback control (sensing and processing)

  • Navigation

  • Temperature and speed monitoring


Scheduling periodic tasks

Scheduling periodic tasks

  • Preemptive scheduling is an effective approach for scheduling real-time DSP systems

    • modularity simplifies the overall design

  • Application can be viewed as a collection of independent tasks or jobs

    • complexity is reduced as the functionality becomes encapsulated into a set of well defined tasks


Scheduling periodic tasks1

Scheduling periodic tasks

  • Systems designed using preemptive scheduling are also more maintainable

    • issue of changes to one task in the system affecting other jobs in the system is removed

    • New functionality can easily be added by adding a new task


Scheduling periodic tasks2

Scheduling periodic tasks

  • Preemptive scheduling approach also makes the system more efficient

    • preemptive scheduling is more efficient at utilizing time slots that may not be fully utilized

  • Scheduling algorithms

    • rate monotonic scheduling

    • deadline monotonic scheduling


Cost of handling event c 4

cost of handling event C = 4

Periodic Arrivals with Fixed Cost of Processing

4

4

4

---- 10 ----

periodic arrivals. period T = 10

System Utilization = C/T = .40

System will be able to meet all deadlines. It can finish processing arrivals before the next arrival occurs.


Rate monotonic analysis

Can a second periodic event be accommodated?

4

4

4

---- 10 ----

1. periodic arrival, period T = 10 and C=4

2. periodic arrival, T=10 and C=3 ??


Rate monotonic analysis

Can a second periodic event be accommodated?

4

4

4

---- 10 ----

1. periodic arrival, period T = 10 and C=4

2. periodic arrival, T=10 and C=3 ??

System Utilization C/T = .70


Rate monotonic analysis

How about 2nd periodic event with T=6 and C=3?

4

4

4

---- 10 ----

1. periodic arrival, period T = 10 and C=4

2. periodic arrival, T=6 and C=3 ??


Rate monotonic analysis

How about 2nd periodic event with T=6 and C=3?

4

4

4

---- 10 ----

1. periodic arrival, period T = 10 and C=4

2. periodic arrival, T=6 and C=3 ??

System Utilization C/T = .90


Rate monotonic analysis

Task #1

Task #2

--6--

4

4

4

---- 10 ----

Event #2

Event #1

If we process Event #1 before Event #2 then,

2nd event processing will not complete before the next comparable event occurs

Can’t Meet Deadline!


Rate monotonic analysis

Task #1

Task #2

--6--

4

---- 10 ----

Try Event #2 before Event #1-

We still cannot complete task 1 before the next task 2 event occurs at t=6

unless...

Event #2

Event #1


Rate monotonic analysis

Task #1

Task #2

--6--

4

---- 10 ----

Try Event #2 before Event #1-

We still cannot complete task 1 before the next task 2 event occurs at t=6

unless…we Interrupt task 1

Event #2

Event #1


Rate monotonic analysis

Task #1

Task #2

--6--

4

---- 10 ----

Try Event #2 before Event #1-

We still cannot complete task 1 before the next task 2 event occurs at t=6

unless…we Interrupt task 1

Event #2

Giving event #2 priority means that we can meet our deadline IF we preempt the processing of event #1 when event #2 occurs

Event #1


Rate monotonic analysis1

Rate Monotonic Analysis


Rate monotonic analysis2

Rate Monotonic Analysis

  • Assume a set of “n” periodic tasks

    • period Ti

    • worst case execution time Ci

  • Rate-monotonic priority assignment

    • task with a shorter period (higher rate) assigned a fixed higher priority


Rate monotonic analysis3

Rate Monotonic Analysis

  • Rate Monotonic scheduling addresses how to determine whether a group of tasks, whose individual CPU utilization is known, will meet their deadlines

    • assumes a priority preemption scheduling algorithm

    • assumes independent tasks (no communication or synchronization)


Rate monotonic analysis4

Rate Monotonic Analysis

  • restriction of no communication or synchronization may appear to be unrealistic, but there are techniques for dealing with this

  • Each task is a periodic task which has a period T, which is the frequency with which it executes


Rate monotonic analysis5

Rate Monotonic Analysis

  • An execution time C, which is the CPU time required during the period

  • A utilization U, which is the ratio C/T

  • A task is schedulable if all its deadlines are met (i.e., the task completes its execution before its period elapses.)

    • A group of tasks is considered to be schedulable if each task can meet its deadlines


Rate monotonic analysis6

Rate Monotonic Analysis

  • RMA is a mathematical solution to the scheduling problem for periodic tasks with known cost

    • assumption is that the total utilization must always be less than or equal to 100%

      • Any more and you are exceeding the capacity of the CPU

      • Are you asking for more computing power than you have? IF so, forget it!


Rate monotonic analysis7

Rate Monotonic Analysis

  • For a set of independent periodic tasks, the rate monotonic algorithm assigns each task a fixed priority based on its period, such that the shorter the period of a task, the higher the priority


Rate monotonic analysis8

Rate Monotonic Analysis

  • For three tasks T1, T2, and T3 with periods of 5, 15 and 40 msec respectively the highest priority is given to the task, T1, as it has the shortest period, the medium priority to task T2, and the lowest priority to task T3

    • priority assignment is independent of the applications “priority” i.e. how important meeting this deadline is to the functioning of the system or user concerns


Rate monotonic analysis9

Rate Monotonic Analysis

  • A mathematical solution to the scheduling problem for Periodic Tasks with known Cost

  • Tasks will have:

    • Cost (Time to complete a task)

    • Period (Time between events)

    • Utilization ( Cost/Period)

  • Assumption

    • Total Utilization must always be <= 100%


3 levels of analysis using rma

3 levels of analysis using RMA

  • Utilization bound test

  • Completion time test

  • Response time test


Utilization bound test

Utilization bound test

  • If this simple rule is followed, then all tasks are guaranteed to meet their requirements if the following holds true;


Utilization bound test1

Utilization bound test

  • In this rule, the bound is 1.0 for harmonic task sets

  • A task set is said to be harmonic if the periods of all its tasks are either integral multiples or sub-multiples of one another

    • On the average, for random Cs and Ts, this number will be about 0.88.


Utilization bound test2

Utilization bound test

  • Theory is a worst case approximation

  • For a randomly chosen group of tasks, it has been shown that the likely upper bound is 88%

    • Harmonic periods can give even higher upper bounds

    • The algorithm is stable in conditions where there is a transient overload


Utilization bound test3

Utilization bound test

  • In this case, there is a subset of the total number of tasks, namely those with the highest priorities that will still meet their deadlines


Example of ub test

Example of UB test

  • Task t1: C1=20; T1= 100; U1 = .2

  • Task t2: C2=30; T2= 150; U2 = .2

  • Task t3: C3=60; T3= 200; U3 = .3

    • The total utilization for this task set is .2 + .2 + .3 = .7. Since this is less than the 0.779 utilization bound for this task set, all deadlines will be met.


Example can these 4 tasks be scheduled

ExampleCan these 4 tasks be scheduled?

  • Can the system run and meet all hard deadlines?

TaskCiTiUi

1310.30

2312.25

3416.25

4720.35


Rate monotonic analysis

ExampleCan these 4 tasks be scheduled?

TaskCiTiUi

1310.30

2312.25

3416.25

4720.35

  • Can the system run and meet all hard deadlines?

  • NO! The Total Utilization = 115%


Example

Example

TaskCiTiUi

1620.30

2416.25

3312.25

Can these tasks always meet their deadlines?

Total Utilization = 80%

It MAY be possible - Rate Monotonic Scheduling applies!


Rate monotonic theorem

Rate Monotonic Theorem

  • For PERIODIC Tasks

  • Most frequent task gets highest priority

  • THEOREM (Simple Version)

    • IF the utilization of all tasks is less than or equal to 69%, then all tasks will ALWAYS meet their deadlines


Are these tasks schedulable

Are These Tasks Schedulable?

TaskCiTiUi

1220.10

2416.25

3312.25

4120.05


Rate monotonic analysis

Are These Tasks Schedulable?

TaskCiTiUi

1220.10

2416.25

3312.25

4120.05

Yes. Total CPU Utilization is 65% < 69%


Rate monotonic analysis

Are These Tasks Schedulable?

TaskCiTiUi

1220.10

2416.25

3312.25

4320.15


Rate monotonic analysis

Are These Tasks Schedulable?

TaskCiTiUi

1220.10

2416.25

3312.25

4120.05

Total CPU Utilization is 65%

???


Rate monotonic analysis

Priority Inversion

Taskh

Taskmed

Tasklow

Priority

inversion

Normal

execution

Execution in

critical section


Rate monotonic analysis

Unbounded Priority Inversion

Taskh

Uncontrolled priority inversion

Taskmed

Taskmed

Tasklow

Priority

inversion

Normal

execution

Execution in

critical section


Motor control example

Motor control example

  • Single DSP will be used to control a motor

  • DSP will also be responsible for interfacing to an operator using a keypad, updating a simple display device, and sending data out one of the DSP ports

  • The operator uses the keypad to control the system


Motor control example1

Motor control example

  • The motor speed must be sampled at a 1 kHz rate

  • A timer will be used to interrupt processing at this rate to allow the DSP to execute some simple motor control algorithms

  • At each interrupt, the DSP will read the motor speed, run some simple calculations, and adjust the speed of the motor accordingly


Motor control example2

Motor control example

  • Diagnostic data is transmitted out the RS232 port when selected by the operator using the keypad


Simple motor control

Simple motor control

Motor Drive

Motor

Tach

RS232 Data Out


Motor control example3

Motor control example

  • The first step in developing a multitasking system is to architect the application into isolated independent execution threads

    • tools available to help the system designer during this phase

  • This architecture definition will produce data flow diagrams, system block diagrams, or finite state machines


Motor control example4

Motor control example

  • Four independent threads in this design;

    • main motor control algorithm which is a periodic task, running at a 1kHz rate

    • keypad control thread which is an aperiodic task controlled by the operator

    • display update thread which is a periodic task executing at a 2 Hz rate


Motor control example5

Motor control example

  • data output thread which runs as a background task and outputting data when there is no other processing required


Requirements

Requirements

Requirements

Control motor speed (1 Khz sampling rate – dV/dT)

Accept keyboard commands to control the motor, change the display, or send data out the

RS232 port

Drive a simple display and refresh 2 times per second

Send data out the RS232 port when there is nothing else to do


Independent execution threads

Independent execution threads

Motor

Motor

Control

Motor

DAC

control

ADC

Tach

algorithm

Drive

Keypad

Keypad

System

control

Control algorithm

control

Display

Display

Display interface

algorithm

control

Remote

Remote

McBSP

RS

-

232

algorithm

output


Motor control example6

Motor control example

  • Relative priority of the threads must now be determined

  • Since this motor control example is a real-time system (there are hard real-time deadlines for critical operations to complete), there must be a priority assigned to the thread execution


Motor control example7

Motor control example

  • One hard real-time thread

    • motor control algorithm

    • must execute at a 1 kHz rate

  • Soft real-time tasks in the system as well

    • display update at a two hertz rate is a soft-real time task (this is a soft real-time task because although the display update is a requirement, the system will not fail if the display is not updated precisely twice per second.)


Motor control example8

Motor control example

  • keypad control is also a soft real-time task but since it is the primary control input, it should have a higher priority than the display update

  • remote output thread is a background task that will run when no other task is running


Motor control example9

Motor control example

  • Motor control system will be designed to use a hardware interrupt to control the motor control thread

    • Interrupts have fast context switching times (faster than that of thread context switch) and can be generated from the timer on the DSP


Assignment of priorities

Assignment of priorities

Task

Rate

Priority

Periodic or

Activation

aperiodic

mechanism

Motor control

1 kHz

1

Periodic

Hardware Interrupt

Keypad

5 hertz

2

Aperiodic

Hardware Interrupt

control

Display

2 hertz

3

Periodic

Software interrupt

control

Remote output

Background

4

Aperiodic

Idle loop (runs

l

continuously in the

background)


Motor control example10

Motor control example

  • Example of a rate monotonic priority assignment;

    • the shorter the period of the thread, the higher the priority

  • Along with the priority, the activation mechanism is described

  • The highest priority motor control thread will use a hardware interrupt to trigger execution


Motor control example11

Motor control example

  • Hardware interrupts are the highest priority scheduling mechanism in most real time operating systems

  • The keypad control function is an interface to the environment (operator console) and will use a hardware interrupt to signal the keypad control actions

    • This priority will be at a lower priority than the motor control interrupt


Motor control example12

Motor control example

  • Display control thread will use a software interrupt to schedule a display update at a two hertz rate

    • Software interrupts operate similar to hardware interrupts but at a lower priority than hardware interrupts (but at a higher priority than threads)

  • Lowest priority task, the remote output task, will be executed as an idle loop


Motor control example13

Motor control example

  • idle loop will runs continuously in the background while there are no other higher priority threads to run

  • The highest priority thread, the motor control thread, is a periodic thread

    • Like many DSP applications this thread processes data periodically, in this case at a 1 kHz rate


  • Motor control example14

    Motor control example

    • This motor control example is actually a multi-rate system

      • multiple periodic operations in the system (motor control and display control, for example)

      • threads operate at different rates

      • DSP RTOSs allow for multiple periodic threads to run


    Motor control example15

    Motor control example

    • For each of these threads, the DSP system designer must determine the period the specific operation must run and the time required to complete the operation

    • The DSP developer will then program the DSP timer functions in such a way to produce an interrupt or other scheduling approach to enable the thread to run at the desired rate


    Motor control example16

    Motor control example

    • Most DSP RTOSs have a standard clock manager and API function to perform this setup operation


    Periodic threads

    Periodic threads

    Clock source

    Periodic clock

    Periodic functions

    n ticks

    tick

    DSP

    Motor control

    timer

    DSP function

    Periodic

    Selectable

    Function

    source

    m ticks

    manager

    Display control

    DSP function

    tick

    User

    Defined

    clocking


    What happened on mars

    What Happened on Mars ?


    What happened on mars1

    What happened on Mars ?

    • Mars pathfinder “flawless” in early days of mission

      • unconventional landing with airbags

      • deployment of Sojourner rover

      • gathering and transmitting data back to earth

    • A few days into the mission the Pathfinder began experiencing total system resets, each including losses of data


    What happened on mars2

    What happened on Mars ?

    • Press reported these as “software glitches”

    • VxWorks RTOS provides preemptive priority scheduling of tasks

      • tasks executed as threads

      • priorities assigned reflecting relative urgency of the tasks


    Rate monotonic analysis

    low priority -

    infrequent execution

    medium priority

    high priority -

    frequent execution

    meteorological

    data

    gathering

    task

    bus

    management

    task

    communication

    task

    mutex

    information bus

    What happened on Mars ?


    Rate monotonic analysis

    What happened on Mars ?

    • Combination worked fine most of the time

    • Possible for interrupt to occur that caused the long running medium priority task to be scheduled during the short interval while the high priority task was blocked waiting on the semaphore that the low priority task had.


    Rate monotonic analysis

    What happened on Mars ?

    • Watchdog timer would go off, notice data bus task not in use for some time, conclude that something bad went wrong, and initiate a total system reset

    • Classic case of priority inversion


    How was this debugged

    How was this debugged ?

    • VxWorks can run in trace mode, recording interesting events.

    • JPL engineers spent hours in lab trying to reproduce the problem on the ground.

    • When finally reproduced, the trace data indicated the priority inversion problem


    How was this problem corrected

    How was this problem corrected?

    • Mutex object accepts boolean parameter indicating whether priority inheritance should be used

    • Initialized with parameter off

      • if on, the low-pri thread would have inherited the pri of the high-pri thread

      • medium pri thread would never have been executed


    How was this problem corrected1

    How was this problem corrected?

    • VxWorks has a C language interpreter that allows C commands to be executed on the fly

    • JPL engineers left this in the software

    • Changed global variables by uploading a short program to the spacecraft

    • No more system resets occurred after re-programming!


    Analysis and lessons

    Analysis and Lessons

    • Diagnosing this problem as a black box would have been impossible

      • trace data was required

    • Leaving debugging facilities in the system saved the day

    • Time critical situations requires additional correctness measures even at the expense of some performance


    Human nature deadline pressures

    Human nature, Deadline Pressures

    • One or two system resets had occurred on the ground prior to launch

    • Never reproducable or explainable

    • “it was probably caused by a hardware glitch”

    • Engineer focus caused part of the problem

      • extremely focused on ensuring quality and flawless operation of landing software

      • the occasional glitch was dismissed


    Importance of good theory algorithms

    Importance of good Theory/Algorithms

    • Some of the heros were people from CMU who published a paper years ago on the priority inversion problem

      • “An Approach to Real-Time Synchronization” IEEE Transaction on Computers, Vol39, pp1175-1185, September 1990


  • Login