The robustness of Linux is widely acknowledged, but it can’t quite match the microsecond management of a real-time operating system (RTOS) for time critical situations such as CNC machine instructions, vehicular control, or health sensor collection. If your software must record, manage, or control events within a narrow and precise time window and you’re invested in Linux for core development, you can consider some of these strategies for handling time-critical tasks without abandoning your familiar environment.
I’ve been working on that exact problem for the last couple weeks. My solution for now is rt patch and a dedicated cpu core for rt tasks. This already works pretty reliable, but I notice small delays from time to time. I gather from the article that my problem might be page swapping. I don’t know how to improve that, yet.
Also for anybody working on rt problems: I highly recommend the
stress-ngtool for stress testing and finding bottlenecks of your system.If you’re working on something that truly needs faster response times at the kernel, you might be better off looking at Zephyr or FreeRTOS for more consistency. “Real-time” mode in the plain Linux sense is just a series of patches which work towards one goal (skipping schedulers and such), but not all coherently working together. Other RTOS’s out there are designed from the outset to streamline such things.
That’s why many modern SoCs have a smaller core for realtime in addition to larger application processors. TI Sitara (Beaglebone) has 2 fast custom arch coprocessors for IO with access to most pins and the ability to DMA into the AP’s address space. All Raspberry Pis up through Pi4 run a proprietary ThreadX runtime on a graphics processor (VPU) to handle bootstrapping the ARM APs, housekeeping, and a large part of the IO.
K. Cool.
But how does this answer OPs questions?