Real-Time and Real-Fast Performance of General-Purpose and Real-Time Operating Systems in Multithreaded Physical Simulation of Complex Mechanical Systems

Abstract

Physical simulation is a valuable tool in many fields of engineering for the tasks of design, prototyping, and testing. General-purpose operating systems (GPOS) are designed for real-fast tasks, such as offline simulation of complex physical models that should finish as soon as possible. Interfacing hardware at a given rate (as in a hardware-in-the-loop test) requires instead maximizing time determinism, for which real-time operating systems (RTOS) are designed. In this paper, real-fast and real-time performance of RTOS and GPOS are compared when simulating models of high complexity with large time steps. This type of applications is usually present in the automotive industry and requires a good trade-off between real-fast and real-time performance. The performance of an RTOS and a GPOS is compared by running a tire model scalable on the number of degrees-of-freedom and parallel threads. The benchmark shows that the GPOS present better performance in real-fast runs but worse in real-time due to nonexplicit task switches and to the latency associated with interprocess communication (IPC) and task switch.

Performance Assessment of Linux Kernels with PREEMPT_RT on ARM-Based Embedded Devices

“…The actual time measuring adds almost no overhead since it is in the order of a few tens of nanoseconds. The same negligible overhead is observed by Garre et al [72] where they conclude that the time difference is below 100 nsecs.…”

The Real-Time Linux Kernel

“…Sharing data among processes-i.e., sharing data be-tween threads in different address spaces-can also have an impact on the real-time workload, since we need to employ synchronization mechanisms for that. Concerning the Interprocess Communication (IPC) services, Garre et al (2014a) showed increased latencies for PREEMPT_RT with respect to the vanilla kernel in the magnitude of tens of μs for operations on semaphores. This is an expected result due to the throughput degradation introduced by PREEMPT_RT.…”

“…In 2014, Garre et al (2014a;Garre et al 2014b) showed that RTAI and Xenomai can reach task switch times on average less than 1μs, while PREEMPT_RT cannot break the microsecond barrier. The evaluation was performed running two threads with a busy loop containing a scheduler yield syscall.…”