Real-Time Support "PREEMPT_RT" For Linux Held Up Due To Lack Of Funding

[Linuxxx]

This is wrong on so many levels, we're actually enjoying good performance and scalability today due to things merged from the RT-PATCH, and there is more things in there that fixes more issues.

And realtime is *predictable* nothing else - but then, just like kill -9 -1 as root will do bad things, you can do bad things with a realtime scheduler.

Could You please specify what is factually wrong with Ubuntu Studio's warning about hard real-time kernels on a desktop system?

[mppix]

I'm just throwing the opinion of Ubuntu Studio's take on this here for further discussion:

Wow, I don't know who is in charge of this at Ubuntu but this is ridiculous.

Yes, a real-time scheduler can lock out a user when it runs our of processing resources.
However, also running out of memory resources can lock out a user. So what? Did they every hear of a reset button?
It is also trivial to implement an automatic kill signal if enough real-time interrupts don't complete or don't get served.. You want this anyway because the system is not doing what you expect it to do in these conditions.

Also, real-time applications are not 'still there' but are gaining traction fast.
Cars need real-time processing of video and sensor input and are increasingly using gpu support for compute.
Also, real-time communication is picking up quickly to support real-time processing. Real-time (AVB/TSN) ethernet is getting quite popular in audio - MAC already implements it. It is also gaining traction in automotive and the process industry.

Currently, the above is primarily implemented in FPGAs but people are certainly looking into leveraging general-purpose hardware for cost and flexibility. Linux seems certainly well positioned to play a key role here.

[poncho524]

This reminds me openssl. I suspect he'll need a heartbleed moment for traction. But I hope it doesn't need to get that far.
https://arstechnica.com/information-...-fund-openssl/

Unfortunately preemt_rt is nothing like openssl. Openssl runs the world. Not many folk seem to be using preempt_rt.

[linner]

I'm pretty sure Ubuntu Studio is not done by Canonical. It's an officially recognized derivative but it's not an official version of Ubuntu.

At the very least Canonical has contributed a lot of work making the desktop more "pretty" than it used to be. It used to be full of awful looking fonts and other poor desktop rendering. I'm sure they've given back work in other areas too. They kind of have to considering 99% of the software they distribute is GPL.

[Guest]

Wow...no funding that is a strange surprise - so much companies are profiting from RT Linux.

As long as they're getting it for free, they won't bother.

[Gps4life]

Can somebody explain to me why you need a real time kernel for music production ?
I make music, on openSUSE tumbleweed with LMMS.

I am not using a real time kernel, mostly because it does not exist any more for openSUSE.
When I started making music, I remember installing a real time kernel, because I was advised to do so.

I never noticed any difference though, between a real time kernel and the default kernel.

[CochainComplex]

Unfortunately preemt_rt is nothing like openssl. Openssl runs the world. Not many folk seem to be using preempt_rt.

Well i guess RT Linux usage is not so obvious but mostlikely used in fields where indeed money flows. That makes it sad. Besides of music/hifi Hardware which might be more niche. RT Linux ist used where obviously time correctness is important that means everything from realtime controlling manufacturing lines on huge production sites, military equipment up to rather new fields like autonomous driving. It's not the nerdy hobbiest in the basement with tight budget.

[puleglot]

Yeah, the RT patches are essential for live audio performances, I really hope it gets sorted out

These days you should just use a standard kernel with CONFIG_PREEMPT=y, CONFIG_IRQ_FORCED_THREADING=y and boot with "threadirqs" in kernel cmdline. You still need to assign priorities to IRQ threads manually though.

[kbios]

These days you should just use a standard kernel with CONFIG_PREEMPT=y, CONFIG_IRQ_FORCED_THREADING=y and boot with "threadirqs" in kernel cmdline. You still need to assign priorities to IRQ threads manually though.

Well I tried the ubuntu lowlatency kernel with threadirqs and I was still getting xruns in jackd, since I switched to the realtime kernel I got exactly zero

[poncho524]

Well i guess RT Linux usage is not so obvious but mostlikely used in fields where indeed money flows. That makes it sad. Besides of music/hifi Hardware which might be more niche. RT Linux ist used where obviously time correctness is important that means everything from realtime controlling manufacturing lines on huge production sites, military equipment up to rather new fields like autonomous driving. It's not the nerdy hobbiest in the basement with tight budget.

I understand that it is the Goal of preempt_rt to perform machine control. However in industry it has not been proven and is not used in that way. It is more of a "it would be nice if this worked, but unfortunately we'll have to stick w tried and true RTOSs, so let's wait and see until then."