| 4th RTL Workshop: Improving the Responsiveness of Linux Applications in RTAI |
by Luca Marzario, Luca Abeni, and Giuseppe Lipari
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)
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
Got a HOT tip?
please tell us!
Click here for a profile of each sponsor:
|
Check out the latest Linux powered...
|
 |
|
|
|
Also visit our sister site:
Sign up for LinuxDevices.com's...
news feed
|
|
