---
layout: post
title: "Mixed Hard Real-Time and High-Performance Computing on Multicore Processors"
date: 2015-01-01
thumb: thumbnail-rtdemo.jpg
tags: [x86, Real-Time Computing]
share: true
comments: true
---

I want to show a nice demo that we created for a [real-time project](http://www.lfbs.rwth-aachen.de/content/628.html) at the Chair for Operating Systems, RWTH Aachen University.
The project was mainly developed by [Georg Wassen](http://www.wassen.net/) and the demo was created in context of [Stephan Alt's bachelor thesis](http://www.lfbs.rwth-aachen.de/content/628.html).

The x86 architecture is so widespread and cheap that it is increasingly implemented in embedded and real-time systems with high performance needs.
On one hand, this allows to use common operating systems and available software.
But on the other hand, general-purpose operating systems do not support real-time needs sufficiently.
A number of special real-time OS (RTOS) exist, but they generally do not support commodity software. In addition, a variety of operating system extensions are available, but they are tied closely to supported versions of a kernel.
To analyze the applications of multicore architectures in real-time computing, we realized hard real-time in a userspace process without (or with only minor) modifications to the kernel.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script src="https://techblog.lankes.org/assets/js/jquery.fitvids.js"></script>
<script>
        $(".container").fitVids();
</script>
<iframe width="560" height="315" src="https://www.lankes.org/videos/rtdemo.mp4" frameborder="0"> </iframe>

With real-time scheduling, the high-priority tasks are executed preferentially, but they are still interfered by interrupts and unpredictable latencies in system calls.
The goal was to execute code on one (or some) of the cores without (or with only minor) interference with the operating system. This comes close to executing code without an operating system directly on the processor.
To allow the interaction between the shielded code and the rest of the system, an interface was developed that is designed with regard to hard real-time needs.

An exemplary system with a quad-core processor was designed as follows: One core executes hard real-time code.
This core has interrupts deactivated and the code does not call any system calls after initialization.
A second core executes some real-time scheduled tasks that connect the hard real-time tasks to the user-space processes and provide services like asynchronous system calls.
The two remaining cores are free for arbitrary programs to use as much computing power as available.

The video shows such a system.
In principle the applications in this video captures a picture or a video, converts it to a black-and-white picture and finally draws it on a oscilloscope. The different tasks are separated in different processes. 
The real-time challenge is drawing of the picture on the oscilloscope.
If this task doesn't fulfill the real-time requirements we will not get a stable image on the oscilloscope.

The left side of the video shows the GUI to control the whole application and the right side the view on the oscilloscope.
With the GUI is it possible to switch to different scheduling models. In the first part of the video, traditional Linux methods are used to optimize the real-time behavior.
For instance, sched_settaffinity  is used to bind each task on a specific core.
Therefore, the load is distributed over all cores. However, the cores have to handle interrupts and other OS tasks, which interferes the real-time behavior.
With our approach the cores are isolated and separating off the Linux kernel.
Afterwards the application runs bare-metal on its own core, which reduces the interferences and creates a more stable image on the oscilloscope.

Preliminary studies are published at [Springer](http://dx.doi.org/10.1007/978-3-642-24658-6_5) and should help to understand our approach. 
