Abstract

RTAI is a real-time kernel that permits to execute, on the same physical machine, both hard real-time applications and the Linux Operating System. RTAI is particularly useful when dealing with real-time processes that needs a guaranteed low response-time to interrupts. By using a fixed priority scheduler provided with RTAI, it is also possible to schedule periodic hard real-time, and to guarantee the schedulability of the system. In this framework, Linux is assigned the lowest possible priority, and it is scheduled in background, i.e. when no other real-time task requires execution. This is the simplest way to guarantee that the behaviour of the real-time tasks is not compromised by the behaviour of Linux applications. However, in certain cases, under high real-time load, this method can be too restrictive for Linux applications. In certain cases, it is useful to mix hard real-time and soft real tasks activities in the same system. Hard real-time tasks represent critical activities that must finish before their assigned deadline, otherwise the system correctness is compromised. Soft real-time system represent non critical real-time activities: they are required to finish before their deadline, but occasional deadline misses do not compromise the correctness of the system. The most popular example of soft real-time application is a multi-media player: if some video frame is not displayed on time, or if it is skipped, nothing catastrophic happens. The ratio of deadline misses over a given interval of time can be taken as a measure of the Quality of Service (QoS) experienced by the final user: the lower the dealine miss ratio, the better the QoS. Soft real-time multimedia applications are usually executed on Linux mainly because many drivers, libraries and tools for video and sound systems are already available on Linux. When soft and hard real-time applications share the same physical machine, one possibility is to schedule hard real-time tasks as RTAI tasks, so guaranteeing a bounded response time; and soft real-time tasks as Linux processes. However, since Linux is assigned the background priority, the amount of execution time assigned to Linux processes over a given time interval depends on the requirements of the RTAI tasks and can vary a lot from interval to interval. Therefore, the amount of execution time that multimedia streams will receive is quite irregular, and it is difficult to guarantee a-priori a certain level of QoS. In this paper, we propose to apply a well-established technique in the real-time system literature, called Resource Reservation, to RTAI. In particular, we changed the RTAI scheduler to implement the Earliest Deadline First (EDF) scheduling policy and the Constant Bandwidth Server (CBS). With CBS, every task is assigned a capacity Q and a Period P, with the meaning that a task is allowed to execute at least Q unites of time every P units of time. A hard real-time task is assigned a capacity Q greater or equal to its worst case computation time and a period P equal to the task's period. Linux is assigned a capacity and a period as well, that depend on the QoS requirement of the soft real-time applications that execute on Linux. The system is schedulable if $sum_i{frac{Q_i}{P_i}}$. At run-time, every task has a remaining capacity q and an absolute deadline d. According to EDF, the task with the earliest deadline is scheduled to execute. At run-time, Linux is treated exactly as any other hard real-time task: initially, it is assigned an absolute deadline $d = P$ and a remaining capacity $q = Q$. When the capacity of Linux is finished, its priority is decreased by postponing its absolute deadline to $d = d + P$, and its capacity is recharged to $q = Q$. In this way, Linux cannot jeopardize the behaviour of the hard real-time tasks, but it is guaranteed a minimum execution time of Q every period P. This mechanims has very little overhead at run-time. Moreover, it has another advantage in the debug phase. During the development of a hard real-time task, it can happen that the task goes into an infinite cycle. For example the task might actively wait for a condition that does never happen. With a pure fixed priority scheduler, it is quite difficult to see what happens, because Linux is scheduled in background and will never execute again. Instead, with our scheduler, Linux is guaranteed a minimum execution time every period: therefore, the programmer can still record the trace and see the logs indicating the situation. In this paper, we implemented the proposed scheduler under RTAI. It is worth to point out that the proposed mechanism is very general, and it can be implemented with little effort in RT-Linux as well. Then, we run a series of experiments that show the advantages of using our mechanism over a pure fixed priority scheduler with Linux in background. We run some simple hard real-time application consisting of 5-10 tasks with different loads, and a mpeg-player under Linux that receives the multimedia stream from a remote host through ethernet. We measured the jitter experienced by the mpeg player: by using methodology, the “regularity” of the player is much higher than using the plain fixed priority scheduler. The paper is organized as follows: after a brief descrpition of the Constant banwidth Server (CBS), we describe our implementation in RTAI and discuss the overhead. Then, we describe the experimental setup and we report the results. Finally, we draw the conclusion and discuss future improvements.

Read full paper (PDF download)

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.