Loading in 5 sec....

Advanced Embedded Systems, BAE 5030 Presentation Topic: Rate Monotonic AnalysisPowerPoint Presentation

Advanced Embedded Systems, BAE 5030 Presentation Topic: Rate Monotonic Analysis

Download Presentation

Advanced Embedded Systems, BAE 5030 Presentation Topic: Rate Monotonic Analysis

Loading in 2 Seconds...

- 115 Views
- Uploaded on
- Presentation posted in: General

Advanced Embedded Systems, BAE 5030 Presentation Topic: Rate Monotonic Analysis

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

Advanced Embedded Systems, BAE 5030

Presentation Topic: Rate Monotonic Analysis

By Aswin Ramachandran

aswin.ramachandran@okstate.edu

A simple scheduling algorithm were priorities are assigned to tasks at the same priority level !

Do the less time consuming jobs first.

Tasks are not processed in the order it is received.

Ensures deadlines and response times are met.

Important to consider while assigning tasks to be dispatched in the Time-triggered and Hybrid Schedulers.

Real-time scheduling priority algorithms are classified into:

Static-priority – Design time (remains constant through out its life-time). Example:RMA

Dynamic-priority – Run time based on the execution tasks & upcoming deadlines.

Mixed-priority – Uses both.

RMA enables us to understand, analyze and to predict the timing behavior of real-time software systems.

Improves the system’s,

Dependability &

Evolvability or Reusability (ease at which a system can adapt to new technology changes).

Terms to understand:

Ti – Period at which the task gets executed. It is also the maximum time that a task can take to finish (deadline). Example: Finishing Assignments

Ci – Time to execute the task ( Ci <= Ti )

Ui – Utilization ( Ci / Ti )

where i is a task. U (n) = C1/T1 + C2/T2…Cn/Tn

Task 1: C1=25ms T1= 50ms; Utilization (CPU usage) = 50 %

Task 2: C2=40msT2=100ms; Utilization (CPU usage) = 40 %

Total CPU Utilization = 90 %

PROBLEM!

Task 2

consumes

more CPU

time and

causes the

Task 1 to miss

the deadline.

Time Graph (a)

- Utilization Bound
C1/T1 + C2/T2…Cn/Tn <= n(2^1/n –1)

Converges to

only

approx. 70%

usage of CPU.

Adding more Tasks Costs CPU time!

- If this inequality is satisfied, all of the tasks will always meet their deadlines.
- If U(n)is greater than 100%, the tasks cannot be completed, which is obvious.
- But if, [ n(2^1/n –1) < U(n)<= 1],
MORE PRECISE TESTING IS REQUIRED!

Task 1: C1=25ms T1= 50ms; Utilization (CPU usage) = 50%

Task 2: C2=40ms T2=100ms; Utilization (CPU usage) = 40%

Total CPU Utilization U(n) = 90 %

- Though U(n) = 0.9, it worked as we saw with no problems when proper priority where assigned.
- Let’s consider a second example

Task 1: C1=25ms T1= 50ms; Utilization (CPU usage) = 50%

Task 2: C2=30ms T2= 75ms; Utilization (CPU usage) = 40%

Total CPU Utilization U(n) = 90 %

- Example 2:
- Task 1: C1=25ms T1= 50ms; Utilization (CPU usage) = 50%
- Task 2: C2=30ms T2= 75ms; Utilization (CPU usage) = 40%
- Total CPU Utilization U(n) = 90 %

Time Graph (b)

Proves that Utilization Bound Test is INCONCLUSIVE, when [ n(2^1/n –1) < U(n)<= 1 ]

Hence we need a more conclusive testing in this bound.

Schedulability (2nd Test): COMPLETION TIME TEST

- For a set of period independent, periodic task, if each task meets its deadline with worst-case overheads (IPC, OS operations etc), then the deadline will always be met.
- COMPLETION TIME TEST:
- Where Wi is the completion time of task i
- If after several iterations i.e.(n)
- Wi <= Ti, then the tasks are schedulable.

Schedulable if we proveWi <= Ti,

Example 1:Total CPU Utilization U(n) = 90 %

Task 1: C1=25ms T1= 50ms; Task 2: C2=40ms T2=100ms

For Task 1: 1<= j < i , in this case i = 1

n = 0: W1 = 25 + 0=> Task1 is schedulable since 25ms < 50ms

For Task 2:1<= j < i , in this case i = 2, where I

n = 0; W2(1) = 40 + 0 = 40 ms

n = 1; W2(2) = 40 + [ 40/50] * 25 = 65 ms

n = 2; W2(3) = 40 + [ 65/50] * 25 = 90 ms

n = 3; W2(4) = 40 + [ 90/50] * 25 = 90 ms

n = 4; W2(5) = 40 + [ 90/50] * 25 = 90 ms

Condition PROVED!

{ W2 , completion time converges before the deadline. Hence the 2 Tasks were schedulable as seen in the time schedule }

Let find out how this test helps to analyze Example 2

- Example 2:Total CPU Utilization U(n) = 90 %
- Task 1: C1=25ms T1= 50ms; Task 2: C2=30ms T2=75ms
- For Task 1: 1<= j < i , in this case i = 1, ( same as Example 1)
- n = 0: W1 = 25 + 0=> Task1 is schedulable since 25ms < 50ms

- For Task 2:1<= j < i , in this case i = 2, where i is the task.
- n = 0; W2(1) = 30 + 0 = 30 ms
- n = 1; W2(2) = 30 + [ 30/50] * 25 = 55 ms
- n = 2; W2(3) = 30 + [ 55/50] * 25 = 80 ms
- n = 3; W2(4) = 30 + [ 80/50] * 25 = 80 ms
Condition NOT PROVED, Since W2(4) > 75 ms

- {hence the 2 Tasks were NOT schedulable as seen in the time schedule }

- All tasks are periodic and not interacting with each another ( all tasks are independent ).
- Deadlines are always the end of the period.
- No interrupts (but hybrid scheduling!).
- Rate monotonic priorities assigned (priorities based on the task rate).
- All tasks are on a single processor.
- Zero context switch overhead. (stack dispelling)
- Tasks do not suspend themselves.

- Modeling context switching
- Schedulability with priority inversion
- By finding the blocking time of the low priority process.

- Schedulability with Interrupts
Idea behind RMA:

Identify the sources of blocking & manage them.

- Tri-Pacific Software, IncRAPID RMA
http://www.tripac.com/html/tech-bkgd-rma.html

- Rate-Monotonic Analysis in the C++ Type System, Deters, Gill, Cytron
http://www.cse.wustl.edu/~cdgill/RTAS03/published/deters__rma_cpptypes.pdf

- gRMA - a graphical tool for Rate Monotonic Analysis of real-time systems (Free tool)
http://www.tregar.com/gRMA/

References:

1. Introduction to Rate Monotonic Scheduling by David Stewart and Michael Barr

http://www.netrino.com/Publications/Glossary/RMA.html

2. Rate Monotonic Analysis, http://www.csie.ntu.edu.tw/~ktw/rts/ch-rma.pdf

3.Rate Monotonic Analysis, www.sei.cmu.edu/str/descriptions/rma_body.html

4. Rate Monotonic Analysis, http://cslab.snu.ac.kr/course/rts03/notes/rt_c32rm.ppt