4 ms·

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

by calvinmorrison 3y ago

refulgentis 3y ago
...yes, after realtime support lands
- lumb63 3y ago
  A lot of realtime systems don’t have sufficient resources to run Linux. Their hardware is much less powerful than Linux requires. Even if a system can run (RT-)Linux, it doesn’t mean it’s suitable for real-time. Hardware for real-time projects needs much lower interrupt latency than a lot of hardware provides. Preemption isn’t the only thing necessary to support real-time requirements.
  - skyde 3y ago
    what kind of Hardware is considered to have "lower interrupt latency"? Is there some kind of Arduino board I could get that fit those lower interrupt latency required for real-time but still support things like Bluetooth?
    - lumb63 3y ago
      Take a look at the Cortex R series. The Cortex M series still has lower interrupt latency than the A series, but lower processing power. I imagine for something like Bluetooth that an M is more than sufficient.
  - refulgentis 3y ago
    Sure but that was already mentioned before the comment I was replying to. Standard hardware not being great for realtime has nothing to do with hypothetical realtime Linux.
  - rcxdude 3y ago
    realtime just means execution time is bounded. It doesn't necessarily mean the latency is low. Though, in this sense RT-linux should probably be mostly thought of as low-latency linux, and the improvement in realtime guarantees is mostly in reducing the amount of things that can cause you to miss a deadline as opposed to allowing you to guarantee any particular deadline, even a long one.
tyingq 3y ago
I'm guessing it's not that technical experts will be choosing this path, but rather companies. Once it's "good enough", and much easier to hire for, etc...you hire non-experts because it works most of the time. I'm not saying it's good, just that it's a somewhat likely outcome. And not for everything, just the places where they can get away with it.
- froh 3y ago
  nah. when functional safety enters the room (as it does for hard real time) then engineers go to jail if they sign off something unsafe and people die because of that. since the challenger disaster there is an awareness that not listening to engineers can be expensive and cost lifes.
  - deleted 3y ago
    [deleted]
synergy20 3y ago
no you don't, you use a true RTOS instead. linux RTOS is at microseconds granularity but it still can not 100% guarantee it, anything in cache nature (L2 cache, TLB miss) are hard for hard real time. a dual kernel with xenomai could improve it, but it is not widely used somehow, only used in industrial controls I think. linux RT is great for audio, multimedia etc as well, where real-time is crucial, but not a MUST.
- froh 3y ago
  > anything in cache nature (L2 cache, TLB miss) are hard for hard real time yup that's why you'd pin the memory and the core for the critical task. which, alas, will affect performance of the other cores and all other tasks. and whoosh there goes the BOM... which again as we both probably are familiar with leads to the SoC designs with a real time core microcontroller and a HPC microprocessor on the same package. which leads to the question how to architect the combined system of real-time microcontroller and compute power but soft real time microprocessor such that the overall system remains sufficiently reliable... oh joy and fun!
  - synergy20 3y ago
    that's indeed the trend, i.e. put a small RTOS core along with a normal CPU for non-real-time tasks, in the past it's done on two boards: one is a MCU another is a typical CPU, now it's one one, very important for where RTOS is a must, e.g. robotics. How the CPU and MCU communicate is a good question to tackle, typically chip vendors provide some solutions, I think OpenAMP is for this.
snickerbockers 3y ago
Pretty sure most people who think they need a real-time thread actually don't tbh.
rcxdude 3y ago
really depends on your paranoia level and the consequences for failure. soft to hard realtime is a bit of a spectrum in terms of how hard of a failure missing a deadline actually is, and therefore how much you try to verify that you will actually meet that deadline.
eschneider 3y ago
The beauty of multicore/multi-cpu systems is that you can dedicate cores to running realtime OSs and leave the non-hard realtime stuff to an embedded linux on it's own core.
snvzz 3y ago
This is why the distinction between soft and hard realtime exists. Linux-rt makes linux actually decent at soft realtime. PREEMPT_RT usually results on measured peak latency for realtime tasks (SCHED_RR/SCHED_FIFO) on the order of a few hundred usec. Standard Linux lets latency go to tens of milliseconds, easily verifiable by running cyclictest from rt-tests for a few hours while using the computer. Needless to say, this is unacceptable for many user cases, including pro audio, videoconference and even gaming. In contrast, AmigaOS's exec.library had no trouble yielding solid sub-millisecond behaviour in 1985, on a relatively slow 7MHz 68000. No amount of patching Linux can give you hard realtime, as it is about hard guarantees, backed up by proofs built from formal verification, which Linux is excluded from due to its sheer size. There's a few RTOSs that are formally verified, but I only know one that provides process isolation via the usual supervisor vs user CPU modes virtualization model: seL4.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

refulgentis 3y ago

...yes, after realtime support lands

lumb63 3y ago
A lot of realtime systems don’t have sufficient resources to run Linux. Their hardware is much less powerful than Linux requires. Even if a system can run (RT-)Linux, it doesn’t mean it’s suitable for real-time. Hardware for real-time projects needs much lower interrupt latency than a lot of hardware provides. Preemption isn’t the only thing necessary to support real-time requirements.
- skyde 3y ago
  what kind of Hardware is considered to have "lower interrupt latency"? Is there some kind of Arduino board I could get that fit those lower interrupt latency required for real-time but still support things like Bluetooth?
  - lumb63 3y ago
    Take a look at the Cortex R series. The Cortex M series still has lower interrupt latency than the A series, but lower processing power. I imagine for something like Bluetooth that an M is more than sufficient.
- refulgentis 3y ago
  Sure but that was already mentioned before the comment I was replying to. Standard hardware not being great for realtime has nothing to do with hypothetical realtime Linux.
- rcxdude 3y ago
  realtime just means execution time is bounded. It doesn't necessarily mean the latency is low. Though, in this sense RT-linux should probably be mostly thought of as low-latency linux, and the improvement in realtime guarantees is mostly in reducing the amount of things that can cause you to miss a deadline as opposed to allowing you to guarantee any particular deadline, even a long one.

tyingq 3y ago

I'm guessing it's not that technical experts will be choosing this path, but rather companies. Once it's "good enough", and much easier to hire for, etc...you hire non-experts because it works most of the time. I'm not saying it's good, just that it's a somewhat likely outcome. And not for everything, just the places where they can get away with it.

froh 3y ago
nah. when functional safety enters the room (as it does for hard real time) then engineers go to jail if they sign off something unsafe and people die because of that. since the challenger disaster there is an awareness that not listening to engineers can be expensive and cost lifes.
- deleted 3y ago
  [deleted]

synergy20 3y ago

no you don't, you use a true RTOS instead. linux RTOS is at microseconds granularity but it still can not 100% guarantee it, anything in cache nature (L2 cache, TLB miss) are hard for hard real time. a dual kernel with xenomai could improve it, but it is not widely used somehow, only used in industrial controls I think. linux RT is great for audio, multimedia etc as well, where real-time is crucial, but not a MUST.

froh 3y ago
> anything in cache nature (L2 cache, TLB miss) are hard for hard real time yup that's why you'd pin the memory and the core for the critical task. which, alas, will affect performance of the other cores and all other tasks. and whoosh there goes the BOM... which again as we both probably are familiar with leads to the SoC designs with a real time core microcontroller and a HPC microprocessor on the same package. which leads to the question how to architect the combined system of real-time microcontroller and compute power but soft real time microprocessor such that the overall system remains sufficiently reliable... oh joy and fun!
- synergy20 3y ago
  that's indeed the trend, i.e. put a small RTOS core along with a normal CPU for non-real-time tasks, in the past it's done on two boards: one is a MCU another is a typical CPU, now it's one one, very important for where RTOS is a must, e.g. robotics. How the CPU and MCU communicate is a good question to tackle, typically chip vendors provide some solutions, I think OpenAMP is for this.

snickerbockers 3y ago

Pretty sure most people who think they need a real-time thread actually don't tbh.

rcxdude 3y ago

really depends on your paranoia level and the consequences for failure. soft to hard realtime is a bit of a spectrum in terms of how hard of a failure missing a deadline actually is, and therefore how much you try to verify that you will actually meet that deadline.

eschneider 3y ago

The beauty of multicore/multi-cpu systems is that you can dedicate cores to running realtime OSs and leave the non-hard realtime stuff to an embedded linux on it's own core.

snvzz 3y ago

This is why the distinction between soft and hard realtime exists. Linux-rt makes linux actually decent at soft realtime. PREEMPT_RT usually results on measured peak latency for realtime tasks (SCHED_RR/SCHED_FIFO) on the order of a few hundred usec. Standard Linux lets latency go to tens of milliseconds, easily verifiable by running cyclictest from rt-tests for a few hours while using the computer. Needless to say, this is unacceptable for many user cases, including pro audio, videoconference and even gaming. In contrast, AmigaOS's exec.library had no trouble yielding solid sub-millisecond behaviour in 1985, on a relatively slow 7MHz 68000. No amount of patching Linux can give you hard realtime, as it is about hard guarantees, backed up by proofs built from formal verification, which Linux is excluded from due to its sheer size. There's a few RTOSs that are formally verified, but I only know one that provides process isolation via the usual supervisor vs user CPU modes virtualization model: seL4.