29 johla joeha145 rtlinux chimera scheduling

RTLinux versus Chimera

A comparative study in scheduling techniques

Authors:Johan Larsson [email protected]

Joel Hägglund [email protected]

mailto:[email protected]


Table of contents1. Introduction.........................................................................................................................32. RTLinux..............................................................................................................................3

2.1. Basic design principles....................................................................................................32.2. Task initialization and resource allocation......................................................................42.3. Scheduling algorithms and techniques.............................................................................5

3. Chimera...............................................................................................................................63.1. Introduction......................................................................................................................63.2. Scheduling in Chimera.....................................................................................................63.3. Periodic, independent tasks..............................................................................................63.4. Aperiodic tasks.................................................................................................................73.5. Dependent tasks...............................................................................................................8

4. Chimera vs. RTLinux..........................................................................................................95. Conclusions.......................................................................................................................106. References.........................................................................................................................11





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





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 first-out 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





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 techniquesRTLinux 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





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. IntroductionChimera 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 sensor-based 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 ChimeraChimera 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 tasksIn 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





Chimera’s 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 task’s 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, Chimera’s 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 tasksAbove 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 can’t 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.





The creators behind Chimera have solved this by using aperiodic servers [4]. From the scheduler’s 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 CPU-buffer 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 tasksIn 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 1930’s), 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





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.





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 PC’s are a serious limitation to the efficiency of RTLinux on such systems. However, legacy devices are less and less prevalent on PC’s 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 they’re 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 non-realtime 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.





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.





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.pdfhttp://beru.univ-brest.fr/~singhoff/cheddar/publications/stewart92.pdfhttp://citeseer.ist.psu.edu/sprunt90aperiodic.htmlhttp://www.enformatika.org/data/v9/v9-4.pdfhttp://www.ece.umd.edu/serts/bib/manuals/Chimera_book.ps.gzhttp://www.fsmlabs.com/images/stories/pdf/archive/rtmanifesto.pdfhttp://www.linuxdevices.com/links/LK8662675028.htmlhttp://www.linuxdevices.com/articles/AT3694406595.htmlhttp://tldp.org/HOWTO/RTLinux-HOWTO.htmlOperating System Concepts, Silberschatz, Galvin, Gagne





http://tldp.org/HOWTO/RTLinux-HOWTO.html

http://www.linuxdevices.com/articles/AT3694406595.html

http://www.linuxdevices.com/links/LK8662675028.html

http://www.fsmlabs.com/images/stories/pdf/archive/rtmanifesto.pdf

http://www.ece.umd.edu/serts/bib/manuals/Chimera_book.ps.gz

http://www.enformatika.org/data/v9/v9-4.pdf

http://citeseer.ist.psu.edu/sprunt90aperiodic.html

http://beru.univ-brest.fr/~singhoff/cheddar/publications/stewart92.pdf

http://www.ee.umd.edu/serts/bib/thesis/dstewart6.pdf



http://beru.univ-brest.fr/~singhoff/cheddar/publications/stewart92.pdf


29 johla joeha145 rtlinux chimera scheduling

Documents