Linux Very Close To Enabling Real-Time "PREEMPT_RT" Support

[-]

left_shoulder_demon@reddit

I wonder when we can get tickless idle, would love to see my GitLab runner VMs consume exactly 0% CPU while no jobs are running, and 100% CPU going to gcc as long as I don't start more parallel jobs than I have CPUs.

[-]

jaaval@reddit

The preempt-rt project is turning 20 years old so i guess now is a good time.

[-]

Scout339v2@reddit

Isnt Wayland like, 10 years old too?

[-]

left_shoulder_demon@reddit

Free software takes time.

You can only move fast and break things if someone is paying for it.

[-]

coffeejn@reddit

Might take another 80 years at this point. /s

[-]

pqratusa@reddit

What does all of this mean? What does this feature do?

[-]

Coldfriction@reddit

It's necessary in order to use Linux to directly control things like robots and CNC machines. LinuxCNC uses a real time a PREEMPT_RT kernel patch called for example.

[-]

Best-Firefighter-307@reddit

https://ubuntu.com/blog/what-is-real-time-linux-i

[-]

carl-di-ortus@reddit

Please explain like I'm 36 and have a toddler who's 5

[-]

AnotherPersonsReddit@reddit

Accroding to ChatGPT:

Real-time Linux refers to a version of the Linux operating system that is tailored to meet real-time computing requirements. Real-time computing is a type of computing where the system is required to process and respond to inputs or events within a strict timing constraint. This is crucial in systems where timely and predictable responses are essential, such as in industrial control systems, robotics, telecommunications, and various embedded systems.

Here’s a brief overview of what makes Real-time Linux special:

Predictable Timing: Real-time Linux aims to provide predictable and consistent timing behavior, which means it can guarantee that tasks will be executed within specified time limits.
Preemption: Real-time Linux often includes features like enhanced preemption, allowing higher-priority tasks to interrupt lower-priority ones more effectively. This helps ensure that critical tasks get the processor time they need without unnecessary delays.
Kernel Modifications: Real-time Linux generally involves modifications to the standard Linux kernel. One common approach is the use of the PREEMPT-RT patch, which adds real-time capabilities to the kernel. There are also other approaches, like the Xenomai project, which provides a dual-kernel setup to achieve real-time performance.
Latency Reduction: Real-time Linux aims to minimize latency and jitter (variability in response times), which is crucial for applications that require precise timing.
Configuration and Tuning: Real-time performance in Linux often involves configuring and tuning the system to optimize it for real-time tasks, which can include adjusting kernel parameters, scheduling policies, and prioritization of tasks.

In summary, Real-time Linux extends the capabilities of standard Linux to handle applications where timing is critical, making it suitable for environments where predictable and timely responses are essential.

[-]

rszdev@reddit

Pretty helpful

[-]

AnotherPersonsReddit@reddit

But apparently not welcome

[-]

CantankerousOrder@reddit

That’s because it’s only as helpful as posting a “let me Google that for you” type of link. It’s not that it isn’t helpful in most case, it’s just that it isn’t always accurate.

[-]

AnotherPersonsReddit@reddit

Was something inaccurate in in it's response?

[-]

greenguy1090@reddit

I’m not sure - are you?

[-]

rszdev@reddit

Haha the number of downvotes what is wrong with ppl

[-]

AnotherPersonsReddit@reddit

🤷

[-]

kido5217@reddit

bad bot

[-]

TheOtherWhiteMeat@reddit

It's an OS that's mainly meant to run on "appliances" like medical equipment, automotive computers, or on factory assembly line equipment. The idea of "real-time" is that the OS has to respond within a certain amount of time, otherwise a failure is considered to have occurred. It's for situations where computers taking their sweet time to compute something could lead to production failures, or even death.

[-]

Alert-Drive-7546@reddit

....or the truth, it was in the begin somewhat near preemptive and then it was not and they tried to sell that preemptiveness since 20 year to get people from Windows to Linux.

Sure they are nearly at it and you can also make your own Kernel, but hey, a lie is a lie.

BEOS was I thing and NextStep.

[-]

De_Lancre34@reddit

Jesse, what the hell are you talking about?

[-]

rszdev@reddit

Hahha my new prompt to chatgpt

[-]

LocalNightDrummer@reddit

Anybody to provide an ELI5 here in a few lines for neophytes?

[-]

RampantAndroid@reddit

A real time OS must respond to requests immediately. It cannot queue requests and get to them when able.

Think about an aircraft computer for example, it needs to process input in real time.

[-]

beheadedstraw@reddit

Which doesn't really make any sense because RT kernels have been around forever.

[-]

IAm_A_Complete_Idiot@reddit

Fwiw it doesn't mean no buffers or absolutely no queuing I don't think. It just means that you have to be able to hit some deadline. If your queue is bounded, and you can guarantee that the last item in the queue will be processed by the end of the deadline constraints, I think that would be fine for a real time system. It's about being able to rely on your latency always being bounded, even if it may be worse on average.

[-]

Zomunieo@reddit

Real time operating systems have a deadline. They are the parent who never fails to pick you up from school on time, a critical task. They are not the fastest parent. They are not the parent with the most children or the parent who always responds to you immediately or the one with the fastest car or the most money. They are the parent who understands critical tasks and does not let themselves get tied up in lower priority work.

Real time processing is not about responding immediately. It’s not about queuing. It’s not about optimizing for throughout or average latency (both often worse in real time). It’s about never failing to meet a deadline for a critical process.

[-]

MrHighVoltage@reddit

Normal kernels queue tasks so they can be processed very efficiently, with servers, this is even more important (for servers for example, you care about the total throughput, not so much the individual latency, read: the website loads slower for you, but more people can load the website from one server). For Realtime kernels, it is the other way around: you do care about latency, throughput is secundary. Think about vehicle computers, professional audio and video systems... you never want to see or here or feel a stutter there...

[-]

stevecrox0914@reddit

The kernel on a computer manages how everything on your computer talks to each other and what the computer is currently working on.

Normally this is done by indicating the priority of the task and everything is scheduled to make the best use of resources.

A real time operating has a concept of work which must be done immediately.

So if a real time task appears the kernel will literally drop everything its doing to complete it.

It makes much worse use of your resources so apps, etc.. will seem laggy.

However if you think in terms of automated cars, trains, spacecraft, etc.. then there is stuff that needs to be done instantly.

[-]

dve-@reddit

Somehow nobody, not even the long winded answer of the large language model provided an actual use case: audio latency.

With a realtime kernel, you can get lower latency on audio processing. This is useful when a musician wants to hear the processed audio "immediately" (with a low latency) of what they are playing.

Example: using your computer as a software modeled guitar amp. Without realtime patches, the music you monitor is delayed from you hitting your strings.

[-]

ahferroin7@reddit

Input latency also. I’ve seen people do custom game controllers using the USB gadget support with stuff like the Raspberry Pi Zero 2 W, and the good ones pretty much invariably use PREEMPT_RT kernels.

That said, on the audio side, mainline has gotten good enough to manage consistent <10ms latency if you configure userspace correctly, and PREEMPT_RT there has become more about minimizing the variance in latency.

[-]

fellipec@reddit

Wonder how it will work, distros will offer the RT enable kernel as a separated download, or will be the same kernel and we can choose if it uses the real time patch with a config or none of this...

[-]

metux-its@reddit

Some distros already offer rt kernels. IMHO this is only about finally merging the separate patch queue in mainline tree, so it doesnt need to be maintained separately.

[-]

InquisitiveAsHell@reddit

Wondered about this myself. I do audio work on linux (full DAW setup) and some 10-15 years ago I still used to run a separate boot with a real time kernel to ensure low latency without dropouts. At some point though mainline linux introduced scheduling and config changes that allowed for a stable sub 10ms setup with the standard kernel which is good enough for me (linux-rt is readily available with my distro but I don't use it). I'd very much like to see hot-swapping RT options but I also suspect the integration has more to do with maintainability/availability.

[-]

metux-its@reddit

We're talking about hard-RT, not just low-latency. Not needed on average workstations, and it would be really hard to make it runtime configurable (might need runtime patching).

[-]

InquisitiveAsHell@reddit

Not for normal use no, but I remember that back in the day a preempt-rt patched kernel was the only way to do professional grade audio on Linux with a latency that rivaled (and surpassed) what the specialized drivers on windows and mac could achieve. At some point I assume there were changes and new configuration options (soft rt?) introduced to the standard kernel that now enables a "good enough" environment for me, even though a separate linux-rt kernel (hard rt) is still recommended if you need to achieve really low audio latency. Sorry if I get the terminology wrong, it's been a while since I looked into the details.

[-]

metux-its@reddit

Oh, you're talking about 3.0 times. The whole scheduling and irq handling had been rewritten many times since then (and tglx iirc has a huge share in this)

[-]

InquisitiveAsHell@reddit

Sounds about right, looking at the kernel history timeline.

[-]

nordiquefb@reddit

So what does this mean for gaming? Lower latency?

[-]

is_this_temporary@reddit

In general, "Real Time" means "if this deadline isn't met, every single time, something very bad will happen".

Sometimes the "very bad" thing is that a live musician's audio glitches.

Other times it means that people will literally die.

But that doesn't mean that Real Time scheduling's goal is to go as fast as possible. It's explicitly not, and much of the work to guarantee deadlines are met actually makes average performance worse.

Given two options:

A: 120 fps 99.99% of the time, but sometimes a single frame takes 0.1 seconds to render.

B: 20 fps 99.99%, but the slowest time a frame will ever take to render is 0.07 seconds.

If your deadline is 0.9 seconds, or somebody loses a limb, then you go with option B. (Don't ask me why a slow frame chops someone's limb off)

If you're just a gamer, you go with option A.

Even worse, those guaranteed deadlines need to be carefully designed into the software, and video games aren't designed for that. So enabling RT might mean that you get an average of only 20 FPS and you still get some frames that take 0.1 seconds to render. (Or the entire game locks up due to priority inversion)

[-]

Patient_Sink@reddit

(Don't ask me why a slow frame chops someone's limb off)

The absolute most brutal version of screen tearing.

[-]