There are a lot of misunderstandings and shallow information in the article (and in the comments).
I used the RT_PREEMPT patches in 2012/13, so my insight is most certainly rusty, dated and might even be wrong here or there. But still:
First of all, RT_PREEMPT is about realtime as in "hard realtime" for control systems. This has nothing to do with "small latency" (the cycle time could be minutes), but with deadline guarantees, allowing control loops over (realtime) network protocols, etc.
Then, almost all important additions of the RT_PREEMPT patches were mainlined one after the other. The last bits were never mainlined although essential for full preemptive kernel AFAIR, but:
Most "modern" (>15 years) OTS-platform (x86, x86-64) is increasingly unfit for realtime - no matter what kernel/OS you use, because your CPU is not in control. Beginning with DMA, later also "management engines", modern platforms might dethrone your CPU on the lowest ring entirely and for as long as they want, to serve a request/interrupt, e.g. fan control, while your CPU wakes up 500ms later realizing that it missed quite a few deadlines. (Fan control is a bad example, but DMA is not. Also Intel ME!)
This makes almost all Linux PCs inherently unable to reliably keep these guarantees.
This puts the whole "hard realtime on Linux"-project in a pickle - since it requires full control over the platform. And most shops that go this route, will take the small additional step of using something well tested and with vendor support.
And the rest buys platform and OS with support from a trusted vendor.
This hits on the core of why we still use what we do in military aerospace. COTS stuff just can’t hit the requirements nowadays.
Personally the newest X86 I’ve seen in this type of stuff was an 80286; everything newer has been POWER or SPARC of one flavor or another, typically running VXWORKS. I haven’t by any means seen everything though.
Agreed here. I do this type work for a career, and if you need safety critical + real time (which really just means known and bounded time) guarantees, anything with an ME type device that can usurp the cores is generally a no go. Especially if the source for the firmware for said ME is not accessible.
Actually, RedHawk Linux is widely used in the US “defense” industry. It supports modern hardware and even provides real-time performance when using CUDA. It is not exactly the PREEMPT_RT though.
I have actually run into that on one or two things, but there were only peripheral to what I deal with. Drones, aircraft, etc. have all been what I mentioned in my (limited) experience.
I agree that Linux with RT_PREEMPT cannot be hard real-time in the sense that it cannot formally guarantee meeting a deadline due to CPU firmware interrupts.
However in many applications (e.g. robotics) where missing a single deadline will not result in loss of life it works perfectly fine.
The unmaskable interrupts on x86 can be a problem but long terms benchmarking can help with possible edge cases.
Other Linux-based solutions such as Xenomai & RTAI which provide even better performance deserve a mention.
I used the RT_PREEMPT patches in 2012/13, so my insight is most certainly rusty, dated and might even be wrong here or there. But still:
First of all, RT_PREEMPT is about realtime as in "hard realtime" for control systems. This has nothing to do with "small latency" (the cycle time could be minutes), but with deadline guarantees, allowing control loops over (realtime) network protocols, etc.
Then, almost all important additions of the RT_PREEMPT patches were mainlined one after the other. The last bits were never mainlined although essential for full preemptive kernel AFAIR, but:
Most "modern" (>15 years) OTS-platform (x86, x86-64) is increasingly unfit for realtime - no matter what kernel/OS you use, because your CPU is not in control. Beginning with DMA, later also "management engines", modern platforms might dethrone your CPU on the lowest ring entirely and for as long as they want, to serve a request/interrupt, e.g. fan control, while your CPU wakes up 500ms later realizing that it missed quite a few deadlines. (Fan control is a bad example, but DMA is not. Also Intel ME!) This makes almost all Linux PCs inherently unable to reliably keep these guarantees.
This puts the whole "hard realtime on Linux"-project in a pickle - since it requires full control over the platform. And most shops that go this route, will take the small additional step of using something well tested and with vendor support.
And the rest buys platform and OS with support from a trusted vendor.