real time kernel: benefits

Posted Sep 21, 2024 10:07 UTC (Sat) by tekNico (subscriber, #22)
In reply to: real time kernel: benefits by Vorpal
Parent article: The realtime preemption pull request

You are talking about hard real time while not just ignoring, but actively negating the existence of soft real time. "Don't use it" is bad advice. See another reply by aaz for more details.

to post comments

real time kernel: benefits

Posted Sep 21, 2024 11:01 UTC (Sat) by mb (subscriber, #50428) [Link]

I understood is as: Don't use it for machines that only run SCHED_OTHER class.

Which is a perfectly valid statement.

But even if you have certain realtime tasks in the system, that still doesn't mean you need PREEMPT_RT.
Rule of thumb: If you don't know whether you need RT, then you probably don't need it.

PREEMPT_RT is *not* a solution that magically makes your machine realtime capable.
Realtime requires that you have a realtime concept for the whole system (including hardware).
The differentiation between "soft" and "hard" is basically useless. In practice what is really needed are numbers for latencies, deadlines and throughput that you have to achieve and then design your whole system accordingly.

real time kernel: benefits

Posted Sep 21, 2024 22:10 UTC (Sat) by simlo (guest, #10866) [Link] (1 responses)

Are we again confusing the term "hard realtime" with safety critical? For me hard realtime means simply that any deadline violations is bug for the purpose of the program. Some audio stuff might be in this category as the missed deadline can destroy a recording. Soft realtime is where the overall application can live with missed deadlines once in a while - the quality of the system simply drops. The linux kernel can with RT support both - but not safety critical, as that requires certification. But then again: Isn't SpaceX using Linux to fly their rockets and manned capsules, or is that a myth?

real time kernel: benefits

Posted Sep 21, 2024 22:35 UTC (Sat) by excors (subscriber, #95769) [Link]

> Isn't SpaceX using Linux to fly their rockets and manned capsules, or is that a myth?

That is true - see https://lwn.net/Articles/540368/ , or e.g. https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_th... :

> All of our on-board computers either run Linux (with the PREEMPT_RT patch) or are microcontrollers that run bare-metal code. For applications running on Linux we are careful to set up the process and kernel thread priorities correctly to avoid priority inversions. We also generally write our code in a way that maximizes determinism, such as avoiding memory allocation at runtime or unbounded loops. Finally, we have telemetry which indicates the performance of all our processes to ensure that they always meet their deadlines across all phases of flight, even in the presence of unexpected or excess inputs.

> We handle radiation fault tolerance by having multiple computers running simultaneously and voting on their outputs. If one of the redundant computers fails due to radiation, the system is generally unaffected. The faulted computer can be rebooted and reincorporated into the system once it recovers, which restores the original fault tolerance.

But some of the most safety-critical things don't use Linux (specifically the thing that detects if the rocket went wrong and might become a risk to people on the ground, and blows it up before it leaves the exclusion zone):

> The Autonomous Flight Safety System (AFSS - it's all about safety) software runs on a set of microcontrollers independent from the flight computer. It receives sensor inputs directly (e.g. IMU measurements) as well as some computed inputs from the flight computer. A Mission Data Load configures the AFSS for which conditions might require termination of the flight, such as the rocket going way off course, losing all acceleration, etc.