G572 Real-time Systems
Rate Monotonic Analysis
Xinrong Zhou
([email protected])
Real-Time System
Rate Monotonic Analysis 1
RMA
 RMA is one quantitative method which makes it possible to
analyze if the system can be scheduled
 With the help of RMA it is possible to:
 select the best task priority allocation
 select the best scheduling protocol
 Select the best implementation scheme for aperiodic reality
 If RMA rules are followed mechanically, the optimal
implementation (where all hard deadlines are met) is
reached with the highest possibility
Real-Time System
Rate Monotonic Analysis 2
RMA
 System model
 scheduler selects tasks by priority
 if a task with higher priority comes available, task
currently running will be interrupt and the task with
higher priority will be run (preemption)
 Rate Monotonic: priority controls
 monotonic,
 frequency (rate) of a periodic process
Real-Time System
Rate Monotonic Analysis 3
Contents

1.
2.
3.
4.
Under what conditions a system can be scheduled
when priorities are allocated by RMA?
Periodic tasks
Blocking
Random deadlines
Aperiodic activities
Real-Time System
Rate Monotonic Analysis 4
Why are deadlines missed?

Two factors:
1.
2.

Factor 1 can be easily quantified



MIPS
Max bandwidth of LAN
Factor 2 contains



The amount of computation capacity that is globally available,
and
how this is used
Processing capacity that is used by the operating system
Distribution between tasks
RMA goals:


Optimize distribution in such a way that deadlines will be met;
or ”provide for graceful degradation”
Real-Time System
Rate Monotonic Analysis 5
Utilization

Task Ti is dependent on:
1. Preemption of tasks with higher priority

describes relative usability grade of tasks with higher priority
2. Its own running time

ci
3. blocking by tasks with lower priority
 Lower priority tasks contain critical resources
Real-Time System
Rate Monotonic Analysis 6
Example
Task
runtime ci
period Ti
Utilization
Priority
Total utilization U = 88,39%
T1
3
9
33,33%
3
T2
5
15
33,33%
2
T3
5
23
21,73%
1
3
3
3
5
3
1
2
3
10
1
20
23
Missed deadline
Real-Time System
Rate Monotonic Analysis 7
Harmonic period helps
 Application is harmonic if every task’s period is
exact portion of a longer period
Task
runtime ci
period Ti
Utilization
Priority
Total utilization U = 88,32%
T1
3
9
33,33%
3
T2
6
18
33,33%
2
T3
8
36
21,66%
1
3
3
3
6
3
6
6
10
2
20
Real-Time System
30
36
Rate Monotonic Analysis 8
Liu & Layland

Suppose that:
1. Every task can be interrupted (preemption)
2. Tasks can be ordered by inverted period:
 pr(Ti) < pr(Tj) iff Pj<Pi
3. Every task is independent and periodic
4. Tasks relative deadlines are similar to tasks’ periods
 Only one iteration of all tasks is active at one time!
Real-Time System
Rate Monotonic Analysis 9
Liu & Layland
 When a group of tasks can be scheduled by RMA?
 RMA 1
 If total utilization of tasks
n
1
ci
 U n   n(2 n  1)

i 1 T
i
tasks
can
be scheduled so that every deadline will be met
e.g. When the number of tasks increases, processor will be
idling 32% of time!
lim n(2 n  1)  0.68....
1
n
Real-Time System
Rate Monotonic Analysis 10
Variation of U(n) by n
1
0,9
0,8
0,7
0,6
0,5
U(n)
0,4
0,3
0,2
0,1
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16
Real-Time System
Rate Monotonic Analysis 11
Example
 In example below, we get utilization
6/15+4/20+5/30 = 0,767
 because U(3) = 0,780, application can be scheduled
Task
running time ci
period Ti
Utilization
Priority
T1
6
15
0,4
3
T2
4
20
0,2
2
T3
5
30
0,167
1
Real-Time System
Rate Monotonic Analysis 12
Why shorter periods are
prioritized?
Task
runtime ci
period Ti
non RMA
RMA priority
T1
3
5
1
2
T2
4
10
2
1
T1 misses deadline
0
5
T1
In realistic application.
c is small compared with
T. Shortest T first ensures
that negative preemption
effects will be minimized
T2
10
non RMA
RMA
Real-Time System
Rate Monotonic Analysis 13
Why shorter periods are
prioritized?
 Slack: T-c = S
 In example is c2 > T1 – c1
 In practice is c<< T e.g. slack is proportional to the
period
 By selecting the shortest period first, the preemption
effect will be minimized
 NOTE:
 We are primarly interesting in shortening deadlines by
priorities!
Real-Time System
Rate Monotonic Analysis 14
How 100% utilization can be
achieved?
 Critical zone theorem:
 If some number of independent periodic tasks start synchronously
and every task meets its first deadline, then every future deadline
will be met
 Worst-case: task starts at the same time with higher-priority
task
 Scheduling points for task Ti: Ti’s first deadline, and the
end of periods within Ti’s first deadline for every task with
higher priority than Ti
 If we can show that there are at least one scheduling point
for one task, then if that task have time to run one time, this
task can be scheduled
Real-Time System
Rate Monotonic Analysis 15
Overhead
 Periodic overhead
 overhead to make tasks periodic
 overhead to switch between tasks
 System overhead
 overhead of operating system
 UNIX, Windows NT: difficult to know what happens in
background
Real-Time System
Rate Monotonic Analysis 16
Periodic Overhead
 To execute a task periodically, the clock must be read and
the next execution time must be calculated
Next_Time = Clock;
loop
Next_Time = Next_Time + Period;
{ ... periodic task code here ... }
delay Next_Time – Clock;
end loop
 task switch:
 saving and recalling tasks ”context”
add two task switches to the running queue
Real-Time System
Rate Monotonic Analysis 17
Periodic Overhead
 Data can be gathered by benchmarking
 for eCOS operating system with:
 Board: ARM AEB-1 Evaluation Board
 CPU : Sharp LH77790A 24MHz
Confidence
Ave
Min
Max
Var
Ave
Min Function
125.56
102.67
148.00
11.89
50%
25% Create thread
75.16
74.00
211.33
2.13
99%
99% Thread switch
45.69
44.00
46.00
0.38
95%
136.53
135.33
160.00
1.96
95%
42.58
36.67
43.33
0.49
70%
4% Resume [suspended low prio]
thread
95% Resume [high priority] thread
4% Suspend [runnable] thread
Real-Time System
Rate Monotonic Analysis 18
Bad points of ”classic” RMA





It requires preemptive scheduler
blocking can stop the system
aperiodic activities must be ”normalized”
tasks which have jitter must be specially handled
RMA can’t analyze multiprocessor systems
Real-Time System
Rate Monotonic Analysis 19
Blocking
 If two tasks share the same resource, those tasks are
dependent
 Resources are serially and mutually exclusive used
 Shared resources are often implemented using
semaphores (mutex):
 2 operations
get
release
 Blocking causes two problems:
 priority inversion
 deadlocks
Real-Time System
Rate Monotonic Analysis 20
Priority inversion
 Priority inversion happens when a task with a lower priority
blocks a task with a higher priority
 e.g. Mars Rover was lost because of priority inversion
R reserved
Release R
T1
T2
Terminates
Allocates R
Release R
Interrupt
Terminates
Blocking time
T3
Interrupt
Try to allocate R
Real-Time System
Interrupt and allocates R
Rate Monotonic Analysis 21
Deadlock
 Deadlock means that there are circular resource
allocation:
 T1 allocates R1
 T2 interrupt T1
 T2 allocates R2
 T2 try to allocate R1 but blocks  T1 will be run
 T1 try to allocate R2 but blocks
 Both tasks are now blocked
deadlock
Real-Time System
Rate Monotonic Analysis 22
Deadlock
 Deadlocks are always design faults
 Deadlocks can be avoided by
 Special resource allocation algorithms
 deadlock-detection algoritms
 static analysis of the system
Resource allocation graphs
Matrix method
 Deadlocks will be discussed more thoroughly with
parallel programming
Real-Time System
Rate Monotonic Analysis 23
Priority inversion: control of
blocking time
 It is difficult to avoid priority inversion when
blocking happens
 Scheduling using fixed priorities produces
unlimited blocking time
 3 algorithms for minimization of blocking time:
 PIP: Priority inheritance
 PCP: Prioirity ceiling
 HL: Highest locker
Real-Time System
Rate Monotonic Analysis 24
Priority Inheritance

3 rules:
1. Blocked task inherits a temporary priority from the
blocking task with a higher priority (priorityinheritance rule)
2. Task can lock a resource only if no other task has
locked the resource. Task blocks until resources are
released, after which task will continue running on its
original priority (allocation rule)
3. Inheritance is transitive:


T1 blocks T2, and T2 blocks T3
T1 inherits T3’s priority
Real-Time System
Rate Monotonic Analysis 25
Priority inheritance
In the example
Alowest priority
Chighest priority
Real-Time System
Rate Monotonic Analysis 26
Priority inheritance
 Blocking time will be now shorter
 Maximum blocking time for a task
 Length of min(m,n) critical section
 m = number of critical sections in application
 n = number of tasks with higher priority
”chain blocking”
 PIP can’t prevent deadlock in all cases
priority ceiling algorithm can prevent deadlock and
reduce the blocking time
Real-Time System
Rate Monotonic Analysis 27
Priority Inheritance
Real-Time System
Rate Monotonic Analysis 28
Priority Ceiling
1.
Every resource has the highest priority level (”ceiling”):

2.
3.
Highest ceiling value (currently used) is stored in a system variable
called system ceiling
A task can lock or release a resource if


4.
5.
6.
Highest priority level of task which can lock (or require) the resource
It already has locked a resource which has ceiling= system
ceiling, or
Task’s priority is higher than system ceiling
A task blocks until resource will be available and system
ceiling variable decrements
Blocking task inherits its priority from that blocking task which has
highest priority
Inheritance is transitive
Real-Time System
Rate Monotonic Analysis 29
Priority Ceiling
R1 ceiling = Prio B
R2 ceiling = Prio C
system ceiling = R1 ceiling
Real-Time System
Rate Monotonic Analysis 30
Priority Ceiling
 blocking time for c is now 0
 no ”chain blocking” possible
deadlock not possible in any cases
 Complicated implementation
Real-Time System
Rate Monotonic Analysis 31
Highest locker
1. Every resource has highest priority level (”ceiling”):
highest priority of a task which can lock the resource
2. Task can lock or release resource and inherit resources
ceiling + 1 as its new priority level



Simpler than PCP to implement
In practice same properties than PCP
”best” alternative
Real-Time System
Rate Monotonic Analysis 32
Highest Locker
Real-Time System
Rate Monotonic Analysis 33
Cost of implementation
 PIP protocol
 Task generates a context-switch when it blocks
 Task generates a context-switch when it becomes
executable
 Scheduler must keep one queue for semaphores of tasks
ordered by priorities
 Every time new task needs a semaphore, scheduler must
adjust tasks priority to the resource owner’s priority
Owner (task) must possible inherit the priority
 Every times resource is released, disinheritance
procedure is executed
Real-Time System
Rate Monotonic Analysis 34
Costs of implementation
 PIWG ( Performance Issues Working Group) has
developed benchmarks for comparing scheduling
algorithms
Test
Description
Fixed-Priority
tasking
PIP Tasking
PIP Overhead
T0001
a call without parameters
28,5s
30,9s
+8,42%
T0004
T0001 with selective wait
for two calls
40,5s
45,2s
+11,60%
T0006
T0004 with 10 tasks
46.7s
54,5s
+16,49%
Real-Time System
Rate Monotonic Analysis 35
Cost of implementation
 Note:
 If the protocol is not in operating system, it must not be
implemented by itself. (application level=>huge
overhead)
 ”No silver bullet”
Scheduling protocol can only minimize the possibility of
blocking
Blocking must be prevented by improved design
Real-Time System
Rate Monotonic Analysis 36
Similarities of scheduling
protocols
Protocol or
policy
Decrements
blocking time
limited blocking
time
Prevents
deadlocks
POSIX
implementation
Fixed-Priority
No
No
No
SCHED_FIFO
scheduling policy
PIP
Yes
No
No
PRIO_INHERIT
synchronization
protocol for
mutex
Priority Ceiling
Yes
Yes
Yes
PRIO_PROTECT
synchronization
protocol for
mutex
Real-Time System
Rate Monotonic Analysis 37
Algorithms in commercial RTOS
 Priority inheritance




WindRiver Tornado/VxWorks
LynxOs
OSE
eCOS
 Priority Ceiling
 OS-9
 pSOS+
Real-Time System
Rate Monotonic Analysis 38
Deadline Monotonic Priority
Assignment
 RM:
 Shortest period gets the highest priority
 DM:
 Shortest deadline gets the highest priority
 DM gives higher utilization
 Get first the analysis using RM, allocate then
priorities using DM
Real-Time System
Rate Monotonic Analysis 39
Dynamic scheduling
 Priorities are calculated at run time
 Earliest deadline first (EDF):
 Task with shortest time to the deadline executed first
 It is always possible to transform timing plan which meets
deadlines to the timing plan under EDF
EDF is an optimal scheduling algorithm
 It is not simple to show that the system is schedulable using EDF
 RMA is enough in practice
 tasks need not to be periodic!
Real-Time System
Rate Monotonic Analysis 40
EDF: Example





Task
Start
time
ci
absolute
deadline
T1
0
10
30
T2
4
3
10
T3
5
10
25
When t=0 can only T1 run.
When t=4 has T2 higher priority because d2 < d1
When t=5 has T2 higher priority than T3
When t=7 stops T2 and T3 has higher priority
When t=17 stops T3 and T1 executes
Real-Time System
Rate Monotonic Analysis 41
EDF: test of schedulability
 In general case, we must simulate the system to show that it
is schedulable
 finity criterion gives limits to the simulation
 Let hT(t) be the sum of running times of those tasks in unit T
which have an absolute deadline
Unit of n tasks is not EDF - schedulabl e if :
n c
1.
u  i 1 i  1 or
Ti
it exists
u


2. t  min T  max 1i n d i ,
max Ti  d i 
1  u 1i n


so that hT t   t
Real-Time System
Rate Monotonic Analysis 42
Aperiodic activities


In practice not every event is periodic
Aperiodic activities are often I/O activities
 Connected to the interrupt lines of the CPU
 Processors’ interrupt has always higher priority
than the scheduler of the operating system
 How could the aperiodic events be connected that
the system will be schedulable?
Real-Time System
Rate Monotonic Analysis 43
Aperiodic activities

Look 5 different implementation models:
1. Interrupt handled at hardware priority level
2. Cyclic polling (handled at the os-schedulers priority
level)
3. Combination of 1 and 2 (deferred aperiodic handling)
4. Interrupt handled partially at hardware level and
partially at OS level with a deferred server
5. Interrupt handled partially at hardware level and
partially OS level with a sporadic server
Real-Time System
Rate Monotonic Analysis 44
Hardware handling
 Interrupt handled wholy by interrupt service routine
(ISR)
Benefits
Simple implementation
easy to analyse with RMA
Minimal overhead
Problems
there maybe starving on OS level
RMA: calculate ”pseudoperiod” for ISR based on events incoming
time
use in order to handle event more rapidly
it must be always shown with RMA that applications stay schedulable
even with storm of events
Real-Time System
Rate Monotonic Analysis 45
Cyclic polling
 One task allocate for handling of events
 Hardware must buffer
 Requirements:
 Only one event should happens between two cycles
 Event must be handled before its deadline
If polling task is not executed with the highest priority, its
period should be highest half of the events deadline
Event
0
1
period n
period n+1
5
D
Real-Time System
Processering
10
Rate Monotonic Analysis 46
Cyclic polling
Benefits
Simple implementation
Full control of the overhead
no hardware processing
Problems
Overhead (unnecessary polling)
possibly makes RMA more
complicated
RMA: Calculate a period for the polling task. Execution time will be the
time for handling the event. Suppose that an event is handled at every
cycle
Used even if events happen seldom
it should always be shown with RMA that applications schedulability is
not disturbed by pollings overhead
Real-Time System
Rate Monotonic Analysis 47
Delayed handling
 Partition handling to two parts:
 ISR: handle those tasks that must be handled immediately:
 Reading of hardware registers
 ....
 ”deferred handler” (DH) will be activated that handles the rest of task
Benefits
small amount of hardware processing
DH can handle many different events
Problems
delayed handler is an aperiodic task
RMA: Calculate a pseudoperiod for ISR. Calculate a pseudoperiod for DH:n based of ISR’s
pseudoperiod
The immediate/deferred scheme is a better approach than the full immediate handing
scheme(risk of monopolizing the processor) or the cyclic poll scheme (high overhead)
Real-Time System
Rate Monotonic Analysis 48
Deferred Server
 Delayed handling is still aperiodic
 Idea: make DH periodic
 Server process
 period
 for prevention that server takes all processing capacity,
server under period is given limited execution capacity
 After server goes idle, the consumed processor capacity
can be restored (replenishment period)
 deferred server restores its processing capacity at
the beginning of period
Real-Time System
Rate Monotonic Analysis 49
Deferred server
Event A
0
Event B
4
5
Event C
8
Event D
10
12
15
 execution capacity 1 (one event/period)
 period 4
 server is redo when t=0, but runs first when t=3 e.g.
phase = 3
 RMA analysis needs that every task should be
executable at the beginning of the cycle
Real-Time System
Rate Monotonic Analysis 50
Sporadic server
 sporadic server restores its capacity first after capacity has
been used
 execution capacity 1 (one event/period)
 period 4
 so that A (t=3) use the whole processing capacity, can B be
processed first at t = 3+4=7
Event A
0
3
Event B
5
Event C
Event D
15
10
7
Real-Time System
11
Rate Monotonic Analysis 51
Sporadic server
 sporadic server can be handled as a periodic task with
variable phase
Event A
0
phase=1
Event B
3
No event to handle
5
7
Event C
10
11
phase=2
Real-Time System
Event D
15
Rate Monotonic Analysis 52
Sporadic Server
 Implementation:
 Operating system:
POSIX 1003.1d defines an interface for sporadic server
scheduling
 By own coding:
complicated
Real-Time System
Rate Monotonic Analysis 53
Sporadic server
 Calculation of period:
 hard deadline:
 minimum interarrival time/2
 event deadline/2
 bursty hard deadline:
 server period = 1/event density
 soft deadine:
 M/D/1 queue-analys
 W = average response time
 I = average interarrival time
T  W  I  W  I   2WI
 I in general
 then server runs with the highest priority (e = processing time for an
T  (e  W )  W  e  2WI
event)
2
Real-Time System
Rate Monotonic Analysis 54
Sporadic server
 Control of schedulability
Criterions
Analysis technique
Soft deadline
schedulability of soft deadlines can’t
be quarantied. M/D/1 technique gives
approximate responce times
Hard deadline, deadline=period, no
blocking
RMA 1 and RMA2
Hard deadline, deadline=period,
blocking
RMA 3 and RMA 4
Hard deadline, deadline before or after
period, blocking
Random deadlines
Real-Time System
Rate Monotonic Analysis 55
Example
Event
Description
Processering
(ms)
Period
(ms)
Deadline
(ms)
e1
periodic
5
30
25
e2
hard deadline:
sporadic incoming time, maximal
rate: 23 evens in 150ms
direct processering: 0,1ms
delayable processering: 0,9ms
a hardware queue saves last 23
events
1
-
-
e3
periodic
58
200
200
e4
periodic
127
600
600
 Is this system schedulable?
 Depends on the implementation
Real-Time System
Rate Monotonic Analysis 56
Summary




RMA 1,2
Dealing with blocking.. RMA 3,4
Arbitrary ´deadline
Aperodic tasks
Real-Time System
Rate Monotonic Analysis 57