TIES426 Real-time systems 2009 19(101)

3. Scheduling with RMA

In this chapter we familiarize ourselves with the RMA techniques. RMA stands for Rate
Monotonic Analysis. RMA helps us to determine if a particular set of tasks can be
scheduled in a given environment.
For a short (but not very well illustrated) introduction to this subject, see the literature
survey of Nate Forman:
http://www.ece.utexas.edu/~bevans/courses/ee382c/projects/fall99/forman/litsurvey.pdf

3.1. About Scheduling

What is a schedule? Basically, it’s a timing plan for the tasks. One can say that a timing
plan is possible if and only if every timing requirements (=deadlines) are met. Various
algorithms for creating timing plans exist. A set of tasks T can be scheduled using some
algorithm A if and only if A always generates a possible timing plan for T. In other words,
no matter how we arrange the contents of T, we’ll still receive a possible timing plan.
The scheduling algorithm A is optimal if it always generates a possible timing plan if such
plan exists. Being optimal does not guarantee the minimum execution time of the tasks
(which normally would be called an optimal solution), but it does guarantee that all
deadlines are met (temporal correctivity!).
Scheduling algorithms can be classified as shown on Figure 3.1. This is the “family tree” of
the ancestors of the algorithms. Various versions of each subclass have been created.

Scheduling algorithms

Static scheduling Dynamic scheduling

(offline, clock-driven) (online, priority-driven)

Static priority Dynamic priority

Rate Monotonic (RM) Earliest-Deadline-First

(EDF)

Figure 3.1. Scheduling Algorithm Classification

Static scheduling is something that can be designed with a pen and a paper: The designer
figures out how to order the tasks in order to meet the deadlines. Such scheme can be
implemented using timers, for example (as in the led blink example on chapter 1).
 TIES426 Real-time systems 2009 20(101)

A version of the static scheduling is (weighted) round-robin scheduling (Liu, 61). The jobs
of a round-robin -scheduled systems join to a FIFO queue. The job on the head of the
queue will be executed next. Each job will be executed some predefined time t, and,
unless ready, will be suspended after it has used its time slice. When introducing the
weights to the system, the time slice for each task i will be wit, where wi ≥ 1 is the weight
for task i. By adjusting the weights it is possible to speed up or retard the progress of each
job.
Dynamic scheduling is more flexible, allowing sporadic tasks to be created (the mine pump
and the water level). Dynamic scheduling can be further divided to scheduling operations
with static priorities and dynamic priorities. An example of the former is the Rate
Monotonic method discussed in this course. An algorithm of the latter kind is the Earliest-
Deadline-First (EDF) algorithm. After studying the RMA method a bit we’ll also take a quick
look at the EDF algorithm and try to compare these two.

3.2. Rate Monotonic Analysis

RMA is a quantitative method. It helps us to select the best possible task priority
allocation, the best scheduling protocol and the best implementation scheme for aperioidic
activity. If the RMA rules are followed, the optimal implementation is reached with the
highest possibility. Here “optimal” means that every hard deadline is met. The “highest
possibility”, of course, means that RMA can’t do the impossible. If there are not enough
resources available then the system cannot perform as required.

3.2.1. Basic Assumptions

When applying the RMA we’ll have to make several assumptions about the system. We
assume that tasks are selected for running by priorities. If a task with higher priority comes
available, then the current task is interrupted and the task with higher priority will be run.
This also means that the system is preemptive (or pre-emptive): There is no need for a
task to yield, the system will take care of switching the task. (The opposite of this is, of
course, non-preemptive system, which required all the tasks to voluntarily allow the task
switch to happen, sooner or later…)
The tasks of the system are assumed to be independent and periodic. There is no
connection between the tasks (at this point of the course) and they will be repeated with a
given period. The priorities of the tasks are set based on this period (or frequency) of the
task.
Priorities are assumed to be static, so the task periods also need to be static. (At the
moment we do not consider nonperiodic tasks, we’ll be back with them a bit later.) The
priorities are assigned to tasks in the order of inverted period. Formally,
pr(Ti) < pr(Tj) iff Pj < Pi
(where “iff” stands for “if and only if”.) This means that if task Ti has shorter period than Tj,
then it will be assigned a higher priority value. (What about tasks with equal periods? One
can assume they both will have the same priority value.)
The final assumption is that only one instance of the tasks is active at the same time. This
can be expressed by saying that tasks’ relative deadlines are equal to their periods. This
guarantees that no task will be started again until its deadline.
 TIES426 Real-time systems 2009 21(101)

3.2.2 Notations
We’ll familiarise us with some of the notations used in this course by examining a little
sample system with three tasks, T1, T2 and T3. They each have a certain running time, i.e.
the time (in some units) which it takes the task to complete. The symbol ei is used for the
running time of task i. Each task also has period (marked with Pi), which defines the time
interval between the task runs.

TASK RUNTIME EI PERIOD PI PRIORITY

T1 3 9 3

T2 5 15 2

T3 5 23 1

Table 3.1 A sample system

The priorities of the tasks are small integer values. During this course, the values are
interpreted so that the greatest number indicates the highest priority. In this sample system
(see the table) the task T1 has the highest priority and the task T3 has the smallest priority.
The priority values mean that whenever T1 comes ready when T2 or T3 is running, the
execution will switch to T1.

3.2.3 An Example
Figure 3.2 below illustrates how the set of tasks shown above may run. The highest-
priority task T1 (shown on the first row) is started first. It has the running time of 3 time
units, so after it is completed, the ready task with the highest priority continues. In this
case it is T2, which has running time of 5 time units. When T2 is completed, it is not yet the
time for T1 to restart (since it has the period of 9, and 8 time units have passed). So the
task T3 starts to run.

Figure 3.2: An example

However, after the task T3 has been executing for one time unit, the higher priority task T1
blocks T3:s execution. After T1 is complete, T3 receives additional 3 time units execution
time, until it is time for T2 to run.
Everything goes just fine until t = 23. As seen on the table above, P3 = 23, and hence the
task T3 should be ready at that time. But it is not. T3 misses its deadline by one time unit. It
 TIES426 Real-time systems 2009 22(101)

appears that these tasks cannot be scheduled. (Not at least on the “hard sense”…)
However, if we evaluate the utilization of the tasks, i.e. the amount of (CPU) time used by
the tasks during their period, we note the following:

• Task 1 wants to run 3 time units of its 9 time-unit period, its utilization is 33,33%
• Task 2 wants to run 5 time units of its 15 time-unit period, its utilization is 33.33%
• Task 3 wants to run 5 time units of its 23 time-unit period, its utilization is 21,73%

A simple calculation gives that the total utilization of the system is 33,33 % + 33,33 % +
21,73 % = 88,39 %. In other words, there is 11,61 % of the processor time not required by
any of the tasks. This suggests that there should be enough time for the tasks to run. It
turns out that this is true, if, I repeat, if we’re able to modify the system so that the
application is harmonic.

3.2.3 Harmonic Periods

When the application is harmonic? When each task’s period is an exact divisor of each
longer period. On the example above the periods were 9, 15 and 23. (Their least common
multiple is 9*15*23 = 419175, which is quite a large time and most likely larger than any
deadline on the system). We would like to modify the tasks so that their critical values
appear as on the table shown below:

TASK RUNTIME EI PERIOD PI PRIORITY

T1 3 9 3

T2 6 18 2

T3 8 36 1

Table 3.2 Another system

Now the total utilization of the system will be U = 88.32%, There will still be 11.68% of the
resources available, which is even more than on the previous example. And what’s most
important, all deadlines will be met. The tasks are now scheduled as shown on figure 3.3.

Figure 3.3 Harmonic periods

 TIES426 Real-time systems 2009 23(101)

Of course, it may be impossible to make such radical modifications to the tasks.

Harmonizing an existing system may not be possible, but any change making the system
“more harmonic” may help to get the system running. This problem has a direct connection
to the real-time programming section of the course; designing the system to be harmonic
right from the start is the right solution.

3.3 Mathematical Background

The RMA concept is based on a mathematical theorem published at 1973 by Liu &
Layland. What the theorem says is basically as follows:
Liu & Layland: A group of tasks can be scheduled (so that every deadline will be met) by
RM if the total utilisation U(n), given by

is greater than or equal to the sum of the utilisation of the tasks, i.e.

This theorem has been described as mathematical representation of a pessimistic worst-

case scenario. It appears to leave quite lot resources unused. For example, by calculating
U(n) for couple of small integers we receive the values shown on figure 3.4.

If we have only one task (n=1), then the total utilisation may be 100%. But for two tasks,
U(2) = 0,828. As the number of tasks increases, the allowed utilisation decreases. Figure
3.5 illustrates this phenomenon. Actually, it can be shown, that

lim n → ∞ n(21 / n − 1)= 0.69...

 TIES426 Real-time systems 2009 24(101)

Figure 3.4 U(n) values

1,0
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0,0
1 2 3 4 5 6 7 8 9 10

Figure 3.5 Variation of U(n) by n

(Excel gives U(6000) = 0,693.) This means that with a very large number of tasks the
processor(s) will be idling about 32 % of time.
This version of the Rate Monotonic Analysis method is called RMA 1. It is a simple but
pessimistic way to receive information about system being schedulable or not. However,
as we’ll soon find out, there are systems which can be scheduled even if RMA 1 gives a
negative result. Utilisations exceeding 90% have been known to be schedulable. A fully
harmonic system may have utilisation up to 100%.
To be precise, RMA 1 tells us that an application is schedulable, but it does not tell if an
application is not schedulable. More accurate methods are needed. Quite soon we’ll
encounter the RMA 2 method, published by Lehoczky, Sha and Ding in 1997.
(Concerning the exam of the course, all these formulas will, of course, be given.)
 TIES426 Real-time systems 2009 25(101)

Exercise 3.1: Given the following task properties,

TASK RUNTIME EI PERIOD PI UTILISATION PRIORITY

T1 6 15 0,4 3

T2 4 20 0,2 2

T3 5 30 0,167 1

try calculate (using RMA1) whether the tasks can be scheduled. Is the application
harmonic?

3.3. Why to Prioritize Shorter Periods?

Before moving to the RMA 2 method we’ll take a quick look at the relation between the
periods and the priorities of the tasks. Above we assumed that the priorities are assigned
to tasks in the order of inverted period, pr(Ti) < pr(Tj) iff Pj < Pi, as it was mentioned. Why
so? Let us examine the following system with two tasks:

TASK RUNTIME EI PERIOD PI UTILISATION

T1 3 5 0,6

T2 4 10 0,4

Since there are only two tasks there are only two ways to assign priorities: Either T2 has
higher priority than T1 (shown on the upper part of the Figure 3.6) or the other way around
(the lower part of the Figure 3.6.).
What happens on the first case: T2, the task with the longer period is started first and
completes it run before T1 is started. But since T1 should be ready at time t = 5, it misses
its deadline. Bad!
Having the priorities the other way round produces much better result: T1 is completed at
time t = 3 and T2 is started. The latter runs for two time units until T1 becomes ready again.
Now is T1 run again and completed at time t = 8. T2 continues operation and has just
enough time to complete its run in time.
We may note that this system is harmonic. Since U(2) = 0,828 and the total utilisation of
this system is 100%, RMA 1 would not give positive result. However, one can see that the
scheme shown on the lower part of the Figure 3.6 could continue forever and all deadlines
would be met, despite the 100% utilisation. The big question for the next chapter is, “How
this 100% utilisation can be achieved?”
 TIES426 Real-time systems 2009 26(101)

Figure 3.6 Prioritising shorter periods

One can formalise this matter by using (yet another term of) slack (s), which is defined to
be the difference between the period and the run time values, i.e. si = Pi – ei. In this
example it was so that e2 > s1 = P1 – e1, since P1 = 5 and e1 = 3 which gives s1 = 2, while
e2 = 4 . This shows that T2 will not meet its deadlines if it has lower priority than T1. On the
other hand, e1 = 3 and s2 = 10 – 4 = 6, which suggests that T2 may allow T1 to have higher
priority and still meet its own deadlines. Again, this “slack analyse” gives us some
information what can not be done, but it does not guarantee that something can be done.
In practice, e << P, which makes the slack proportional to the period P. By selecting the
task with the shortest period to have the highest priority we allow it to get the execution
time it needs.

3.5 Summary
Scheduling algorithm is optimal if it always generates a possible timing plan.
Scheduling algorithms can be organised as static (clock-driven) and dynamic (priority-
driven, with static priority such as RM or dynamic priority such as EDF).
RMA assumes premptivity, independency, periodicity and static priorities in the order of
inverted period.
Harmonic periods provide better performance.
RMA gives pessimistic worst-case estimate. It tells if the application is schedulable. It does
not tell that it is not.