SIMULATION FOR MULTIPROCESSOR

REAL-TIME SCHEDULING EVALUATION

Richard Urunuela, Anne-Marie Déplanche, Yvon Trinquet

IRCCyN, UMR CNRS 6597

University of Nantes
1 rue de la Noë, BP 92101, 44321 Nantes cedex 3, France
{richard.urunuela—anne-marie.deplanche—yvon.trinquet}@irccyn.ec-nantes.fr()

Abstract

The increasing complexity of the hardware multiprocessor architectures as well

as of the real-time applications they support makes very difficult even impossi-
ble to apply the theoretical real-time multiprocessor scheduling results currently
available. Thus, so as to be able to evaluate and compare real-time multipro-
cessor scheduling strategies on their schedulability performance as well as en-
ergy efficiency, we have preferred a simulation approach and are developing an
open and flexible multiprocessor scheduling simulation and evaluation platform
called STORM (”Simulation TOol for Real-time Multiprocessor scheduling”).
This paper presents the simulator on which STORM relies and that is able to
simulate accurately the behaviour of those (hardware and software) elements that
act upon the performances of such systems. An example is given to illustrate such
a performance evaluation.This work has been supported by the french Agence
Nationale de la Recherche through the PHERMA project (Contract ANR ANR-
06-ARFU06-003). See http://pherma.irccyn.ec-nantes.fr.
Keywords: Real-time systems, Multiprocessor global scheduling, Simulation

Presenting Author’s Biography

Urunuela Richard is a research engineer of the IRCCyN laboratory in the
”Real-Time Systems” group. Since 2003 he is interested in the design of
real-time systems and more particularly: operating systems, power man-
agement for such systems, and real-time scheduling. At present, he is in
charge of the implementation of STORM, a Simulation TOol for Real time
Multiprocessor scheduling. He is also focusing on the development of en-
gineering tools for helping to the design of power management policies.
Previously he worked around scheduling and power management in the
OBASCO research group at the Ecole des Mines of Nantes.
1 Introduction components and the scheduling rules. The original
need to develop STORM came from the works of the
Multiprocessor architectures are becoming more and PHERMA research project (PHERMA - ”Parallel Het-
more attractive. From single-core designs with heat erogeneous Energy efficient Real-time Multiprocessor
and thermal problems, chip makers are now shifting to Architecture” - is an ANR (French National Research
multicore technologies. While making them decreas- Agency) project (see http://pherma.irccyn.ec-nantes.fr).
ingly expensive, they are making very powerful plat- This project addresses multiprocessor architectures for
forms available. Such platforms are desirable for em- which one needs to evaluate the performances in term
bedded system applications with high computational of energy efficiency for specific hardware and software
workloads such as robot controls, image processing, or architectures.
streaming audio. The additional characteristic of such
applications is to meet some real-time constraints; con-
sequently they require predictable performance guaran- 2 Motivation of our work
tees from the underlying operating system. This has led In comparison with the impressive number of publica-
to renewed interest in multiprocessor real-time schedul- tions and results on real-time scheduling since more
ing: scheduling algorithms together with schedulability than 30 years, few tools are available to apply them.
analysis. So many theoretical results are available but On the one hand, some commercial tools exist for
mainly based on simple hardware and software archi- the complete design and analysis of real-time systems.
tecture models [1]. Obviously they are not freely available, as examples:
These results are difficult to exploit if the assump- RapidRMATM (from Tri-Pacific Software Inc.) or
tions are not satisfied which is the case for modern TimeWiz (from TimeSys Corp.) On the other hand,
hardware and software architectures (processor hetero- open source or free products are available coming from
geneity, cache management, inter-processor commu- the academic community. Some of them are the re-
nications, complex software behaviours, system over- sult of PhD studies that do not overstep the prototype
heads, etc.). Furthermore, due to the specific applica- state without maintenance support. As an example we
tion fields where energy efficiency is critical (battery- can cite [3] or XRMA [4]. Others are more substantial
based embedded systems), power management tech- but do not offer enough flexibility so as to be extended
niques (Dynamic Voltage and Frequency Scaling or Dy- or adapted for new requirements. Some examples
namic Power Management) are inescapable and must are: YASA (”Yet Another Scheduling Analyser”) [5],
be taken into account. MAST (”Modeling and Analysis Suite for real-Time
applications”) [6, 7], Cheddar [8, 9], or TORSCHE
Indeed, in such a context, it is very difficult to evalu- [10, 11]. That is why we decided to implement a new
ate and compare scheduling algorithms on their schedu- tool with the following main design specifications:
lability performance as well as energy efficiency. So
we think that a more global approach is needed in or-
der to explore the adequacy between scheduling poli- • it addresses specifically multiprocessor architec-
cies and (hardware and software) architectures. It is tures (composed of homogeneous or heteroge-
not for us a matter of implementing scheduling algo- neous processors); monoprocessor architectures
rithms on true multiprocessor platform(s) but rather of being the simplest case;
designing an open and flexible framework able to sim-
• it has to be able to take into account: i) the fea-
ulate accurately the behaviour of those (hardware and
tures of hardware architecture: multicore design,
software) elements that act upon the performances of
multiprocessor architecture with shared memory,
such systems. The tool we are working on is called
distributed architecture with communication net-
STORM which stands for ”Simulation TOol for Real-
work, memory architecture (L1 and L2 caches,
time Multiprocessor scheduling” [2]. This multipro-
banked memory); ii) the features concerning en-
cessor scheduling simulation and evaluation platform
ergy consumption for the processors and memo-
is intended to: i) use as input the specifications of the
ries, in particular the capabilities for DPM (Dy-
hardware and software architectures together with the
namic Power Management) and DVFS (Dynamic
scheduling policy; ii) simulate the system behaviour
Voltage and Frequency Scaling);
using all the characteristics (task execution time, pro-
cessor functioning conditions, etc.) in order to ob- • it is a free, flexible, portable and open tool: i)
tain the chronological track of all the ”events” that oc- ”free” because the STORM software is freeware
curred at run-time; iii) compute various real-time met- under Creative Commons License (subsequently it
rics in order to analyse the system behaviour and per- will be available as an open source); ii) ”flexible”
formances from various point of views. For the time means the possibility to program and to add easily
being, engineering efforts on STORM have concerned simulation entities (such as scheduling policies)
mainly its simulator component since it is the retain- through well-defined APIs; iii) ”portable” means
ing element of the platform. For a given ”problem” the possibility to run it on various OS thanks to the
i.e. a software application that has to run on a (multi- Java programming language; iiii) ”open” means
processor) hardware architecture, this simulator is able that the input/output data are formatted using xml;
to ”play its execution” over a specified time interval
while taking into account the requirements of tasks, the • lastly, it is intended to provide a simulation lan-
characteristics and functioning conditions of hardware guage to drive experiments (statistical studies or
 domain explorations) via a simulation controller. that can be conducted using STORM. Together with the
Upstream from the simulator, this controller com- STORM software (release 3.0), examples and (user and
putes the inputs, runs the simulations, and down- designer) guides about STORM are freely available at
stream computes the required metrics from simu- http://storm.rts-software.org.
lation results.
3.1 The functional architecture
The internal architecture of the STORM simulator is
composed of a set of entities built around a simulation
kernel (see Figure 2).
Software (respectively hardware) entities stand for the
tasks and data (respectively processors) that compose
the software (respectively hardware) architecture for
which the simulation is conducted. There are as many
task, data link and processor entities as specified in the
XML input file, and they are automatically instantiated
from the library components. Those libraries provide
a large panel of task behaviours: recurrent, periodic or
aperiodic, with or without activation recording, with or
Fig. 1 The STORM simulator. without deadline abort. It’s also the case for the data
links that enable quite complex synchronization rela-
tions between tasks. For the time, two processor types
are available: a basic one and another with functioning
3 The STORM simulator modes and DVFS capabilities.
As shown by Figure 1, the STORM simulator needs The system entities represent some run-time and oper-
the specification of the studied ”problem” as input. By ating components that are present in real-time multi-
problem, we means a software real-time application, processor platforms.They are the task list manager, the
i.e. a set of tasks with execution requirements, that has scheduler and the memory manager. The task man-
to run on a multiprocessor hardware architecture. It is ager manages task activations and synchronizations in
described in a XML input file in which specific tags accordance with the specifications of the software ar-
and attributes have to be used, and where references chitecture. Thus, at each simulation slot, depending
to predefined components (available in attached Java on the current state, it may interact with the simula-
class libraries) are made. Thus, for such a given prob- tion kernel so as to release or block some task(s). The
lem, the simulator is able to ”play its execution” over a scheduler entity is in charge of allocating the proces-
specified time interval while taking into account the re- sor(s) to the ready tasks depending on the scheduling
quirements of tasks, the characteristics and functioning strategy it implements. Its type is specified in the XML
conditions of hardware components and the scheduling input file and can be chosen among the numerous real-
rules, and with the highest timing faithfulness. As a time global event-driven and time-driven multiproces-
result, a lot of simulation outputs can be computed: ei- sor scheduling algorithms that are available in library.
ther user readable in the form of diagrams or reports, Moreover, thanks to the flexibility of STORM, there is
or machine readable intended for a subsequent analysis no limitation for introducing new scheduling policies as
tool. The user’s interactions with STORM go through a it will be shown in the final paper. Up to now, the mem-
user-friendly graphical interface which is composed of ory manager has not be developed. Its part should be
command and display windows. The figures given after to carry out the behaviour of the elements of the physi-
in the Example section are screen-shots of this GUI. cal memory architecture (memory access bus, memory
We want to point out that the simulation is a discrete bank) that may impact the execution with timing and
time one, i.e. the overall simulation interval is cut into a energy aspects.
sequence of unitary slots [0,1], [1,2],..., [t,t+1], etc., and
simulation moves forward at each instant 0, 1, ...t, t+1, The simulation kernel is at the heart of STORM and has
etc. Thus, at t, the next simulation state (for instant t+1) been thought as simplest as possible. In consequence,
is computed from the current one (of instant t) and the it provides a very few basic services. Due to the dis-
pending simulation events at time t. Moreover only the crete approach for the simulation process, one of them
control behaviour of the software application elements is a time service so as to manage simulation time and to
is captured by the simulation. It means that no applica- indicate the spending of time to the simulation entities.
tive programs run for the tasks, nor true data exchanges Another kernel service is a watchdog service. It enables
between tasks exist, but only task execution times and any entity to ask the kernel to arm a watchdog mecha-
synchronizations are taken into account while simulat- nism so that the specified function of the specified en-
ing. tity will be called when the specified delay expires, as
illustrated on Figure 3. Lastly, the kernel offers a ker-
In this paper, we chose to overview the internal ar- nel message service. For some state change or simula-
chitecture of the simulator and to present an example tion event occurrence, an entity has to inform the kernel
so as to illustrate the kind of performance evaluation by asking it to register a pre-identified kernel message.
 Fig. 2 The simulator architecture.
Fig. 4 The kernel message service.
The kernel is then in charge of processing such a mes-
sage. Depending of the context, it may lead it to send or
not some other information to some other entities. For Entity. It contains the declaration of the methods in-
example (see Figure 4), each time one job of the (peri- volved in the implementation of the different services.
odic) task T1 completes, its STORM entity informs the Depending on the subclasses and the behaviour they
kernel about its completion (thanks to the well iden- must exhibit, those methods may need to be overrided.
tified BLOCK message). Obviously such an indication If the paper is accepted this part can be extended or not
has to be known to the scheduler entity. Moreover since depending on the reviewers’s remarks.
task T1 produces some data, the kernel has to inform as
well the data link entity.

Fig. 5 The UML class diagram.

Fig. 3 The watchdog service.

In summary, the kernel acts as a ”conductor”: at each

4 Example
slot, it processes all the pending kernel messages the
simulation has produced up to now and in accordance In this section we show the use of STORM for the
with the rules it implements, it switches them towards in-depth analysis of a problem. The problem is com-
the appropriate simulation entities. Of course those in- plex enough because it is about finding the solution that
teractions between entities that do not require the con- gives the best result (best throughput and best QoS)
trol of the kernel are allowed to take place in a direct while consuming the minimum of energy. The exam-
way. ple is inspired of a more complex problem: an H264
decoder (image coding / decoding).
3.2 The software architecture
4.1 The problem
The STORM simulator is written in Java programming
language which makes it independent of any execution The experiment we have conducted is concerned with
platform. Figure 5 gives a simplified view of the current the software architecture described in the XML input
UML class diagram of STORM file and depicted in Figure 6 (this task graph has been
gotten from the Graphical User Interface of STORM).
In accordance with Figure 5, we can find there, on
It is composed of 8 tasks (referenced ”Task A” to ”Task
the one side, the SimulationKernel final class that
implements the kernel of the simulator, and on the H”) and 10 data links (shown as top-down transitions
between tasks). It is a data-flow graph with precedence
other side, a set of classes (T ask, Data, P rocessor,
constraints. The periodic task ”Task A” generates peri-
Scheduler, T askListM anager, etc.) and their sub-
classes that model the various simulation entities (some odically (every 20ms) some data on which subsequently
the tasks ”Task B” to ”Task E” work in parallel. Their
of them correspond to the value that has to be given to
outputs (by pair) are required as inputs for the execu-
the className attributes in the input xml file).
tion of the tasks ”Task F” and ”Task G”. Finally, from
All of the subclasses inherit from the superclass the joined outputs of these two previous tasks, ”Task
H” computes some transformation so as to produce the as to conduct a statistical evaluation, 100 simulations
result in the end. This last task is a periodic task be- (with a total duration equal to 1 second for each) have
cause one can thus associate it a deadline that will serve been achieved. During these simulations all the peri-
for the measure of QoS (count of missed deadlines). odic tasks were of ”PTask WAM type”. Then another
Some parameters of the tasks are given in the Table set of 100 simulations have been conducted, all the pe-
1. The tasks ”Task A” and ”Task H” are periodic (20 riodic tasks being of ”PTask NAM type”. In order to
ms) and for the experimentations they will be succes- have a measure for the QoS (number of missed dead-
sively of type ”PTask WAM” (With Activation Mem- line of ”Task H” ) the deadline of this task has been
ory) or type ”PTask NAM” (No Activation Memory). fixed to 25 ms, so 5 ms after its period. The measure for
The other tasks are recurrent ones (type ”RTask”). The the throughput is the number of executions of ”Task H”
chosen rule for computing the actual execution time of during the simulation duration: so the maximum value
task jobs (specified in the XML input file too) is an uni- is 50. Table 2 presents the resulting metrics. The values
form random law between the BCET and WCET values are computed as normalized mean values for the simu-
for all the tasks. The scheduling algorithm is of type lation duration.
”FP P Scheduler” (Fixed Priority full Preemptive) and
all the tasks have the same static priority. All the pro-
cessors are identical and of type ”CT11MPCore”.
Tab. 2 Metric evaluation of the problem
Our intent is to evaluate what is the minimum required
Periodic Number Power Missed Number
number of processors of a multiprocessor architecture
task of (W) deadline of
so as to maximise the output flow (i.e. the number of
type processors executions
”Task H”’s outputs relatively to the number of ”Task
A”’s activations), while minimising its jitter (i.e. the WAM 1 1 45 27.6
variation on the dates where ”Task H”’s outputs are pro- NAM 1 1 39 25
duced) together with minimising the electrical power WAM 2 1.6 23 49.5
consumption. Such a software architecture as well NAM 2 1.6 0.6 49
as our performance evaluation objective are complex WAM 3 1.8 5.3 49.8
enough to prefer a simulation study rather than a (nec- NAM 3 1.8 0.4 49
essary) approximate theoretical one. WAM 4 2 0 50
NAM 4 2 0 50
WAM 5 2 0 50
Tab. 1 Task parameters
NAM 5 2 0 50
Name task BCET (ms) WCET (ms) Task type
Task A 1 3 PTask...
Task B 2 4 RTask
Task C 2 4 RTask
Task D 2 6 RTask From the analysis of the results of the Table 2 the fol-
Task E 2 6 RTask lowing conclusions can be stated:
Task F 2 3 RTask
Task G 2 3 RTask
1. whatever the type of task the best results (through-
Task H 4 6 PTask...
put and QoS) are gotten from 4 processors but the
power is then maximal;

2. using the ”PTask WAM” task type, one gets more

missed deadlines, therefore the QoS is less good
but the throughput is better, from 2 processors;

3. with the configuration using ”PTask NAM” task

type and 2 processors, one consumes 25% less
than with 4 processors; the throughput is only 2%
lower than the maximal throughput; the QoS is
good. This solution seems to be a good compro-
mise.

Fig. 6 The task graph of the software architecture. If necessary it is possible to look finely at the be-
haviour of the tasks using a Gantt diagram. As an exam-
4.2 The experiment and results ple the Figure 7 (such diagrams are accessible through
STORM’s GUI) gotten with ”PTask NAM” task type
So as to determine the minimum number of processors, and 2 processors shows the deadline failure of task H
simulations have been successively conducted with an during the first period. This missed deadline occurs be-
increasing value from 1 up to 5 processors (the perfor- cause it is not possible to have a high degree of paral-
mance metrics do not change beyond 4 processors). So lelism during this period.
 6 References
[1] J.Y-T Leung. Handbook of schedul-
ing:Algorithms, Models, and Performance
Analysis. Chapman & Hall/CRC, New York,
2004.
[2] STORM, May 2009. http://storm.rts-
software.org/.
[3] J. Goossens and Ch. Hernalsteen. A tool for sta-
tistical analysis of hard real-time scheduling al-
gorithms. In 31st Annual Simulation Symposium
, Boston (USA), IEEE Computer Society Press,
pages 58–65, April 1998.
[4] William Henderson, David Kendall, and Adrian
Robson. Improving the accuracy of scheduling
Fig. 7 An example of missed deadline with analysis applied to distributed systems. In Jour-
”PTask NAM” task type nal of Real-Time Systems n o 1, volume 20, pages
5–25, January 2001.
[5] YASA, May 2009. http://yasa.e-technik.uni-
rostock.de/.
5 Conclusion
[6] MAST, May 2009. http://mast.unican.es/.
The intent of our work is in the end to evaluate and com- [7] M. Gonzlez Harbour, J. J. Gutirrez Garca, J. C. Pa-
pare schedulability performance and energy efficiency lencia Gutirrez, and J. M. Drake Moyano. MAST:
of scheduling algorithms and to investigate their ade- Modeling and analysis suite for real time appli-
quacy with regard to the hardware and software archi- cations. In 13th Euromicro Conference on Real-
tecture features of the considered systems. Presently, Time Systems (ECRTS), pages 125–134, Delft
the STORM simulator is able to simulate accurately the (Netherlands), 2001.
execution of a set of tasks over a multiprocessor system. [8] F. Singhoff, J. Legrand, L. Nana, and L. Marcé.
Tasks may exhibit various behaviors and be indepen- Cheddar: a flexible real time scheduling frame-
dent or not. Various scheduling strategies are supported work. In ACM SIGADA Ada Letters, volume 24,
too. As a result, the simulator is not only able to state pages 1–8, December 2004.
about the schedulability of the studied system but also [9] CHEDDAR, May 2009. http://beru.univ-
to characterize its behavior with some measurements brest.fr/ singhoff/cheddar/.
for further analysis. At the present time, our work on [10] P. Šůcha, M. Kutil, M. Sojka, and Z. Hanzálek.
STORM is concerned with: Torsche scheduling toolbox for matlab. In IEEE
Computer Aided Control Systems Design Sym-
posium (CACSD’06), pages 1181–1186, Munich,
• The energy and power aspects: i) we are ex- Germany, October 2006.
panding the hardware component library with pro- [11] TORSCHE, May 2009.
cessors supporting DVFS and DPM; ii) we are http://rtime.felk.cvut.cz/scheduling-toolbox/.
studying how to introduce banked memory pat-
terns; iii) we are integrating the corresponding en-
ergy/power management strategies as new system
entities;

• The memory architecture modelling: since mem-

ory time access can act significantly upon the
global performances of a multiprocessor system,
we are investigating how to model the behaviour
of (different levels of) cache and external mem-
ory and in particular the overhead induced by their
management;

• The evaluation process automation: we are defin-

ing a simulation language to drive the experiments.
Thus the user would be able to describe a ”do-
main” for the simulation inputs and to specify the
metrics to be measured as a result. Then the tool
would automatically build a statistically represen-
tative set of compliant test cases, run their simula-
tions, and output the statistical results.