1 Advanced Embedded Systems, BAE 5030 Presentation Topic: Rate Monotonic Analysis By Aswin Ramachandran

2 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. What does RMA mean …?

3 Objective of RMA 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: T i – Period at which the task gets executed. It is also the maximum time that a task can take to finish (deadline). Example: Finishing Assignments C i – Time to execute the task ( C i <= T i ) U i – Utilization ( C i / T i ) where i is a task. U (n) = C1/T1 + C2/T2…Cn/Tn

4 Lesser the work Higher the Priority! 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)

5 Bounds to satisfy 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!

6 Utilization Bound Test(1 st Test) U(n)<= n(2^ 1/n –1) 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!

7 Though U(n) = 0.9, it worked as we saw with no problems when proper priority where assigned. Let’s consider a second example So how to test schedulability … 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 % 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 %

8 Is this a schedulable task… 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 % 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 Time Graph (b)

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

10 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 = => Task1 is schedulable since 25ms < 50ms For Task 2:1<= j < i, in this case i = 2, where I n = 0; W2(1) = = 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 } Schedulable if we prove W i <= T i,

11 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 = => 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 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 } Let find out how this test helps to analyze Example 2

12 Tests Bounded by Assumptions… 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.

13 Practical Applications 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.

14 RMA Software Tri-Pacific Software, Inc RAPID RMA Rate-Monotonic Analysis in the C++ Type System, Deters, Gill, Cytron gRMA - a graphical tool for Rate Monotonic Analysis of real-time systems (Free tool) References: 1. Introduction to Rate Monotonic Scheduling by David Stewart and Michael Barr 2. Rate Monotonic Analysis, rma.pdf 3. Rate Monotonic Analysis, 4. Rate Monotonic Analysis,