RTLinux versus Chimera

A comparative study in scheduling techniques

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

Table of contents
1.
2.

Introduction.........................................................................................................................3
RTLinux..............................................................................................................................3
2.1. Basic design principles....................................................................................................3
2.2. Task initialization and resource allocation.......................................................................4
2.3. Scheduling algorithms and techniques.............................................................................5
3. Chimera...............................................................................................................................6
3.1. Introduction......................................................................................................................6
3.2. Scheduling in Chimera.....................................................................................................6
3.3. Periodic, independent tasks..............................................................................................6
3.4. Aperiodic tasks.................................................................................................................7
3.5. Dependent tasks...............................................................................................................8
4. Chimera vs. RTLinux..........................................................................................................9
5. Conclusions.......................................................................................................................10
6. References.........................................................................................................................11

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

1. Abstract
In this report, two realtime operating systems, RTLinux and Chimera, are compared and
analyzed, mainly in regard to their scheduling methods. It gives a general introduction to both
systems as well as a more in-depth look at their respective schedulers. The conclusion reached
is that the two systems are very different in many regards, mainly flexibility; the modularity
and customizability of RTLinux, together with its ability to cooperate with regular Linux,
makes it a generalist system that can be used in almost any situation whereas Chimera is more
limited but probably also more efficient.

2. Introduction
The original focus of the report was scheduling, but it turns out that it is meaningless to
discuss the differences between these two systems in that area without first giving proper
descriptions of what they are actually meant to do. Therefore, we begin by describing the
design principles behind each of the two operating systems, in their respective chapters. Only
then can we move on to the schedulers.
Since RTLinux relies on a rather innovative design, a brief description of its resource
allocation techniques is also given. This is interesting because although RTLinux runs tasks in
realtime, it relies on regular Linux, which is not realtime, to handle task initialization.
We then proceed to describe the actual schedulers as they are, before we do the actual
comparisons. We also draw some conclusions on the general useability of these systems,
because the differences not directly related to scheduling are simply too great to ignore. Our
findings from these comparisons can be found in the final chapter.
We hope that this report can be used as a basic foundation for those who are trying to decide
what kind of realtime system they need to use. Chimera and RTLinux represent two vastly
different philosophies and a comparison between the two can help illuminating the fact that
realtime systems do not need as simple and rigid as some believe.

3. RTLinux

3.1. Basic design principles

RTLinux is an attempt to introduce realtime dependability into a non-realtime environment.
The usefulness of a system that can execute tasks both in realtime and whenever-time is
obvious since such a system makes it possible to run very complex tasks that only
sophisticated generalist operating systems can manage while also running tasks that are
guaranteed to execute within a given time frame. This, however, turns out to be difficult to
accomplish.

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

The reason for this is that pure realtime systems quickly grow so complex as to become
unusable as features are added; things such as rendering complex three-dimensional scenes
might be one such case. On the other hand, attempts to introduce realtime capabilities into a
generalist kernel have yielded inferior performance. If the price of dependibility is a system
that runs so slow as to be unusable, the advantage of dependability is lost and the whole
system becomes pointless.
The solution, according to the creators of RTLinux, is to create a small, modular realtime
kernel and let it run the regular operating system as a low-priority thread. By designing the
realtime kernel in such a way that it emulates the system hardware, the power and flexibility
of the regular operating system is preserved. From its point of view, nothing has changed.
Meanwhile, the realtime kernel is free to do its thing.
Part of the design is that the regular operating system can never preempt the realtime kernel,
or any other threads running on that kernel. Also, any interrupts or hardware requests must
first pass through the realtime kernel which then decides if and when the requests are let
through. This means that any non-critical tasks will be delayed until the realtime kernel has
nothing to do other than let the regular operating system run.

Fig. 1: Basic layout of an RTLinux system

Naturally, there is also a need for realtime jobs to be able to communicate with other jobs. For
example, one might have a realtime process that regulates the throttle of a fighter jet and
another process that presents information about how the throttle is being regulated to the pilot
by showing him some sort of graphical representation. In order for this to work, either the
realtime process must be able to update the graphics routine, or the graphics routine must be
able to access memory that contains information left by the control program.
This can be accomplished in two ways in RTLinux shared memory and special first-in firstout buffers. These things will not be covered any further in this paper, but it is important to
point out that they exist in order to show that RTLinux together with a regular Linux
operating system really does comprise one complete system.

3.2. Task initialization and resource allocation

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

RTLinux works under a number of assumptions when it comes to initializing tasks. One of
them is that the actual initialization of any task does not comprise a realtime task in itself.
This includes the RTLinux kernel.
This means that tasks pertaining to initialization can be completely left to the regular Linux
kernel. Booting the system is therefore done exactly as it is on regular Linux systems.
Realtime tasks are compiled as Linux kernel modules and are added to and removed from the
realtime scheduler with regular Linux commands, which is possible thanks to the modular
approach used in the design of the Linux kernel.
Thus adding and removing realtime tasks can be done from a regular command prompt in
Linux or through the POSIX API. This adds enormous flexibility to the system.
Another assumption made by RTLinux is that realtime tasks do not have access to
dynamically allocated memory. Allocating memory is generally very slow and it is difficult to
construct an algorithm to do this in a deterministic time frame. Therefore, any realtime
process must use static memory allocation only.

3.3. Scheduling algorithms and techniques

RTLinux is, just like the regular Linux kernels, highly modular. One of the basic modules of
the kernel is the scheduler, which can be replaced at will by the user. The basic RTLinux
scheduler is very simple and runs jobs in order of priority; at any one time, the highest priority
job is guaranteed to be running. This means that critical tasks can never be preempted by less
critical ones and that few context switches, which are expensive, will be made.
However, the default scheduler allows even realtime tasks to miss their deadlines
occasionally. If this is undesirable, a new scheduler can be written and used instead.
Whatever algorithm one decides to use, regular Linux jobs will be run as subprocesses to the
Linux process. This means that these jobs will be scheduled by another scheduler in the
timeslots where there are no realtime jobs to perform. In other words, there are always two
schedulers active in an RTLinux system. While this might seem inefficient, it is necessary in
order to preserve the flexibility of the system. If RTLinux were to interfere with the Linux
scheduling process, additional restraints would have to be placed on the way the Linux kernel
works. Also, the scheduling requirements for realtime systems are rarely the same as for
generalist systems, so a scheduler that might be great for the RTLinux kernel may very well
prove disastrous for the Linux kernel and vice versa.
There is another consideration to take into account when deciding what scheduling algorithm
to use. It is the issue of how to handle the system timer. Many, if not most, scheduling
algorithms prevent any one process from running indefinitely, preempting it if it runs for too
long. In order to do this, one needs to use a hardware timer, and there are two ways to use it.
Either one lets it run with a fixed period, or one reprograms the timer with a new interval after
each timeslice.
In the first of these two modes, each timeslice will be of identical size. The problem with this
is obvious; different jobs might need timeslices of different size. Some jobs might require
Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

significant system resources while others are trivial and only need a few microseconds of
CPU time every second or so. In this scenario, using the timer in fixed period mode is
obviously not ideal.
In the other mode, it is much easier to adapt to different jobs. However, one might have
hundreds of tiny jobs that each needs very little execution time. Since reprogramming the
timer costs CPU time, there is a real risk in this scenario that the system becomes significantly
slower than it would have been if it had used the first timer mode.
Ultimately, it is clear that RTLinux offers great flexibility when it comes to scheduling.
Generally speaking, flexibility normally comes at the cost of performance. However, lacking
the means to perform any objective tests, we cannot determine if this is the case for RTLinux
as well.

4. Chimera

4.1. Introduction
Chimera is a reliable hard realtime operating system with support for multiple processors. It
brings forward interesting ideas of how to schedule hard or soft, periodic or aperiodic,
dependent or independent tasks at the same time. Chimera was developed by David Stewart
and Pradeep Khosla in Carnegie Mellon University, Pittsburgh for use in all kinds of sensorbased control systems.
In this chapter we will present the choices of scheduling in Chimera. Even though it supports
different types of scheduling, we will focus on the default one, the MUF scheduling
algorithm. At first we will consider how independent, periodic tasks are treated. After that we
will present a more realistic system, where tasks depend on each other and where some events
appear to be of the aperiodic nature.

4.2. Scheduling in Chimera

Chimera supports different types of scheduling including fixed, dynamic or even mixed
priority settings. The default scheduler in Chimera is maximum urgency first (MUF), which
according to Stewart [1] performs at least as well as the commonly used rate monotonic (RM)
scheduling. At first, a short presentation of the fundamental scheduling algorithms to MUF
will be done.

4.3. Periodic, independent tasks

In ordinary rate monotonic scheduling, each process has its own priority based on the period
of the tasks. The more frequent a task is, the higher priority gets assigned to it. This type of
preemptive scheduling has fixed priorities for each task and schedulability bound close to
69% [2] with many tasks in the system. Even though this is just a theoretical number and may
be much higher in reality it is not a efficient enough scheduler to use in Chimera. Since
Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

Chimeras purpose is in the use of sensor-based control systems, a dynamic scheduler is more
seemly.
The earliest deadline first (EDF) scheduling algorithm is dynamic. Whereas in RM each task
has a fixed priority, in EDF each tasks priority is based on when the deadline of that task
occurs. The earlier the deadline, the higher priority of the task. This is, just like with RM, also
a preemptive scheduling algorithm but more suited for dynamic systems since each priority
change during time. In practice, the schedulability bound for EDF is 100% [2], seemingly
optimal. A great disadvantage to EDF is that it is hard knowing exactly which task that failed
in case of some deadline failure. This can occur when the system is overstressed, for instance
when many aperiodic tasks enter the system, all needing to use the CPU at the same time.
However, as written earlier, Chimeras default scheduling algorithm is MUF. It combines the
flexibility of fixed and dynamic priorities. The MUF actually consists of three different
priorities. The criticality and user priority are both static priorities. The dynamic priority is of
course dynamic. Criticality has precedence over the dynamic priority, which in turn has
precedence over the user priority.
In the MUF scheduler, some tasks can be guaranteed to execute even in these overstressed
systems, where the total CPU utilization is over 100%. These tasks form the critical set.
A short description of how the priorities get declared [3]:
1. Sort tasks in RM order.
2. Choose as many tasks as possible, making sure the utilization does not exceed 100%.
These form the critical set mentioned above. Each task in the critical set gets a HIGH
priority. Each process outside of the set gets a LOW priority.
3. Give each task a user priority.
4. The dynamic priority will change during run-time and can be set in different ways.
When scheduling with this algorithm, each task in the critical set must be completed before
any attempt of completing tasks outside of the set. If each task gets assigned a unique user
priority, there will always be one task with the highest priority.
Since the purpose of Chimera is in sensor-based robot systems the MUF scheduling algorithm
is actually quite efficient. Tasks that are urgent and crucial for the system to function properly
will be placed in this critical set, while tasks that are soft realtime (for instance getting output
from sensors) would be placed outside.

4.4. Aperiodic tasks

Above mentioned algorithms is easy to implement for periodic and independent tasks. In
reality there will of course be some aperiodic tasks to handle as well. Consider yourself
driving a modern car, with almost everything computer-controlled. What if you suddenly need
to hit the brakes? Since the CPU of the brake-mechanism really cant know when you need to
stop, this cannot be scheduled beforehand. This is instead an aperiodic task, which just like
periodic tasks have its deadline.

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

The creators behind Chimera have solved this by using aperiodic servers [4]. From the
schedulers point of view, the aperiodic server is just like any other task. It will have its own
priority and be scheduled among the rest of the tasks. From the aperiodic tasks point of views
it acts as a scheduler.
The server can be seen as some kind of polling mechanism which, every time it gets
scheduled, checks to see if any aperiodic tasks need execution. It could also be seen as a CPUbuffer with a server capacity C and a period T. The capacity of the server is equal to the CPU
utilization of it. Each time the server gets scheduled for execution some aperiodic task
consumes from the buffer. When the buffer is empty it could either be filled instantly or filled
when it is scheduled the next time.
If there are no aperiodic tasks to attend to the task will be preempted, letting the periodic tasks
make sure they reach their deadlines. Depending on which algorithm being used, this either
means that every aperiodic task joining the system after the server got suspended will have to
wait until the server starts next time or the server needs to constantly poll and check for
incoming aperiodic tasks. Constantly polling will of course create a lot of overhead, while
waiting until the server starts again will lead to longer response times.

Fig. 1. An example of scheduling aperiodic tasks with an aperiodic server. This is EDF scheduling with the
Deferrable Server.

4.5. Dependent tasks

In reality, tasks depend on each other. Some tasks maybe need input from a number of other
tasks to complete its output correctly. Some tasks simply cannot execute until some other task
is complete. For instance, getting back to the example with the car, what happens when you
brake? In the ordinary braking system (probably in cars from around the 1930s), it would
probably just rely on the hydraulics and the discs pressing against the wheel side. In newer,
modern car systems with ABS brakes the ABS controller needs input from i.e. speed sensors
to accurately control the braking power.
Actually, Chimera supports a lot of different methods for task communication. For instance,
message passing, remote semaphores, shared memory, on-to-one triple-buffer communication
Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

are some methods supported. Shared memory makes it easy scheduling dependent task which
is why that method will be presented here.
In Chimera, multiple processes are run simultaneously on different processors, each
connected to a VMEbus [5]. To solve the problem of dependent tasks, one method is storing
data in a global variable table in an external memory bank connected to the bus. Multiple
tasks will be running on different CPUs simultaneously and some of them may want to get or
store data into the memory at the same time. Since only one task at a time can access the
physical bus, processes need to wait and this will create a lot of overhead. By having a local
variable table in each task and only updating the global table when the local one changes it
will be a lot less waiting. That is, updating input variables when the task starats and updating
output variables when the task has completed its execution. The access to the global variable
table needs to be mutual exclusive though, needing a single semaphore protecting it.

Fig. 2. A chimera system with multiple processors connected to a memory bank via a VMEbus.

If a task wants to read from or write to the global memory it first has to make sure it does not
get preempted during the transfer. By doing this and also having a semaphore protecting the
global table it makes sure all variables are correct. If a task is trying to use the global variable
table and it is locked because of another task (on another CPU of course) transferring from/to
it, the first mentioned task has to wait and poll the lock at certain time intervals. According to
Stewart [1], context switching from and back to a task on a Chimera system requires more
overhead than waiting for and polling the lock, thus waiting is the best solution.
Since each task has a limited of inputs/outputs, each transfer between a local and the global
table have an upper limit. By adding the maximum time a task has to wait for a lock to the
worst-case execution time of that task, dependent tasks can be scheduled just like independent
task mentioned above, thus no changes is needed to the scheduler.

5. Chimera vs. RTLinux

This is just two out of many attempts to create efficient realtime operating systems. Creating
an add-on to the well-known Linux operating system was at first glance quite interesting.
Even though RTLinux could be used in large and complex systems it could also be attractive
to ordinary computer users. For instance, it would be interesting putting RTLinux in as a
substitute for operating systems running on a PDA. Chimera, on the other hand, seems to be a
very special-purpose-kind of operating system for dynamic environments, such as in robots. It
would probably be of no use to ordinary computer users.

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

Regarding the scheduling abilities of the two systems, chimera gives the impression of being
more advanced out of the box. From start you have four different schedulers (one not
mentioned in this paper) to choose from, while in RTLinux it only seems to include the typical
RM and EDF scheduling algorithm. It should be noted though, that in both operating systems,
it is possible to implement your own scheduler.
Both RTLinux and Chimera supports communication between tasks by the use of shared
memory and FIFO-buffers (message passing) but Chimera actually supports a number of
additional methods. However, since Chimera supports multiple processors working together,
sharing data between the tasks of different RTPUSs must be done through some kinds of bus
which creates more overhead and could be rather slow. Comments on the performance of
RTLinux by its creators also indicate that legacy components on common PCs are a serious
limitation to the efficiency of RTLinux on such systems. However, legacy devices are less and
less prevalent on PCs so this is becoming less of an issue.
In both operating systems, it is possible running non-realtime tasks at the same time as both
hard and soft realtime tasks. In Chimera, this can be done with the MUF scheduling
algorithm, putting non-realtime tasks outside of the critical set. In RTLinux this is done by
executing non-realtime tasks as a sub process to the Linux task. The result is actually quite the
same. In both cases the non-realtime tasks will only be executed if there are no realtime tasks
to attend to (meaning theyre all done or there are none in the system).
However, RTLinux has the advantage of running regular Linux as a subprocess. Since Linux
is a very sophisticated system with support for everything from advanced graphics drivers to
internet access and remote protocols, all the possibilities of a non-realtime system is available
to RTLinux. This advantage is even greater as both Linux and RTLinux exist as free, open
source software, which means an adept programmer can adapt both the realtime and nonrealtime kernels to suit his/her specific needs.
With the use of aperiodic servers, Chimera has the ability to schedule sporadic tasks joining
the system. The drawback with this is that the response times of the tasks will fluctuate a bit.
RTLinux achieves the same functionality by reprogramming the schedule timer. This has the
drawback of potentially bogging the system down while still not avoiding the problem of
fluctuating response times.

6. Conclusions
One striking realization we reached when writing this report was that even though RTLinux
and Chimera are so fundamentally different and meant for different target groups, their
scheduling systems are built on very similar principles. They both handle non-realtime tasks
as low-priority processes that run whenever there are no realtime jobs to perform.
The devil, of course, lies in the details. The strength of RTLinux is that it allows the user to
utilize Linux as the non-realtime process, which allows for a daunting amount of flexibility.
However, Linux is (generally) not a small system. If the realtime tasks are too resource
intensive, regular Linux will not be useful because it is in itself a significant resource hog.
Such situations might arise in embedded systems or systems with significant cost limitations.
In such cases, Chimera will probably yield better results.
Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

This brief research has allowed us to catch a glimpse at two realtime operating systems. It is
actually hard telling which one works for the better after this limited time. It would be
interesting putting these two operating systems to test and see which one actually performs
better. Unfortunately, neither the equipment nor the resources were available for us to do that.

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se

7. References
[1] http://www.ee.umd.edu/serts/bib/thesis/dstewart6.pdf , p. 108
[2] Operating System Concepts, Silberschatz, Galvin, Gagne p. 704-707
[3] http://beru.univ-brest.fr/~singhoff/cheddar/publications/stewart92.pdf, p. 139-143
[4] http://www.ee.umd.edu/serts/bib/thesis/dstewart6.pdf. , p. 119-128
[5] http://www.ee.umd.edu/serts/bib/thesis/dstewart6.pdf , p. 128-134
http://www.ee.umd.edu/serts/bib/thesis/dstewart6.pdf
http://beru.univ-brest.fr/~singhoff/cheddar/publications/stewart92.pdf
http://citeseer.ist.psu.edu/sprunt90aperiodic.html
http://www.enformatika.org/data/v9/v9-4.pdf
http://www.ece.umd.edu/serts/bib/manuals/Chimera_book.ps.gz
http://www.fsmlabs.com/images/stories/pdf/archive/rtmanifesto.pdf
http://www.linuxdevices.com/links/LK8662675028.html
http://www.linuxdevices.com/articles/AT3694406595.html
http://tldp.org/HOWTO/RTLinux-HOWTO.html
Operating System Concepts, Silberschatz, Galvin, Gagne

Authors:
Johan Larsson johla@tfk.liu.se
Joel Hgglund joeha145@student.liu.se