So I have PREEMPT_RT in Linux-6.12-rc1. Now what?

[uOpt]

How should I evaluate what PREEMPT_RT does for us in a halfway objective manner? Suggestions welcome. (This is not on my machine with the RME setup, so it's pretty much Focusrite only)

As a non-music first test this is the time to compile the Linux kernel. As expected sys time (in-kernel time) goes up 7%, which translates to about 2% slower total.
PREEMPT_RT compile kernel in 6.12-RC1:
1:05:19 3919.80 real 55138.85 user 5284.97 sys 1541% CPU 5660/867886743 faults
not RT:
1:03:56 3836.23 real 55216.59 user 4951.82 sys 1568% CPU 6234/867666270 faults

This is running on a laptop with i7-1260P and Samsung PM9A1 NVMe.

[gearwatcher]

I don't think puzzle pieces are there for non-developers to leverage it unless the software they were using was already using PREEMPT_RT capabilities.

However I do expect the mainline kernel with RT to behave similarly to the lowlatemcy kernels out of the box for myriad audio related stuff already, given proper userland configuration.

You can follow the links in this rabbit hole for more insight.

https://discourse.ardour.org/t/rt-kerne ... ack/104201

TLDR of it is it's still better to install e g Ubuntu Studio and let the "seasoned pros" do all the dots joining for you

[uOpt]

Is the realtime priority scheduling that we give to jack woven into PREEMPT_RT?

Thanks for that link.

[audiojunkie]

How should I evaluate what PREEMPT_RT does for us in a halfway objective manner? Suggestions welcome. (This is not on my machine with the RME setup, so it's pretty much Focusrite only)

As a non-music first test this is the time to compile the Linux kernel. As expected sys time (in-kernel time) goes up 7%, which translates to about 2% slower total.
PREEMPT_RT compile kernel in 6.12-RC1:
1:05:19 3919.80 real 55138.85 user 5284.97 sys 1541% CPU 5660/867886743 faults
not RT:
1:03:56 3836.23 real 55216.59 user 4951.82 sys 1568% CPU 6234/867666270 faults

This is running on a laptop with i7-1260P and Samsung PM9A1 NVMe.

If it were me, I'd wait until an official kernel is released. Furthermore, you shouldn't need to compile anything, as long as your distro provides the kernel. In addition, to activate the functionality within the kernel, you will have to enable the kernel boot parameters. Finally, if you, like many of us, have already been using the kernel boot parameters of the generic kernel for years, you probably won't notice much (if any) difference is performance than was previously experienced. The reason is, while the patches were out of tree, they were still being compiled into the kernel, and we were still using them. The only main difference now, is that they have been completely mainlined--meaning that the patches, which were maintained out of tree, are now considered "official" and included in tree by default. I use Fedora, and personally don't expect to notice anything different than what I've already been experiencing for years.

In short, kernel 6.12, is the culmination of 20+ years of work to make the real-time code official within the Linux kernel. Even though it is officially sanctioned kernel code now, there won't be a noticeable change for those who have already been using the code through kernel parameters.

I hope this doesn't disappoint you too much. I'm ecstatic about kernel release 6.12, but I want to dispel any misunderstandings and false expectations. That said, if you "haven't" been using the patches all of this time, then you might indeed benefit from this release.

[audiojunkie]

Is the realtime priority scheduling that we give to jack woven into PREEMPT_RT?

Thanks for that link.

Yes.

[uOpt]

There should be a measurable or at least observable problem in audio that PREEMPT_RT solves. Otherwise what is the fuzz that musicians make about?

Regardless of whether it is a distribution's own hacked up RT kernel or 6.12.

[audiojunkie]

The observable difference will be for those who have not been already using and benefitting from the real-time patches. I’ve already been using them, so the new kernel won’t give me much of a noticeable difference.

[mjolnir]

sometimes the RT kernels are less stable than the "stable" kernels LOL
so now the RT features will be in the stable kernels, and therefore new features in stable LOL
did i say that right?

[uOpt]

sometimes the RT kernels are less stable than the "stable" kernels LOL
so now the RT features will be in the stable kernels, and therefore new features in stable LOL
did i say that right?

It certainly is an advantage that it is now Linus-approved. I would not be comfortable running a kernel hacked up by a distribution.

I pounded it quite a bit, no problems observed.

[mjolnir]

that's great news.
even the ext4 speed update in v6.11 is good too!

I was thinking about this again lately... I think the RT update might help reduce MIDI latency.

[mjolnir]

I was thinking about this again.
I wonder what the effect is of some preliminary kernel parameters at boot time.
I'm not very smart about this kind of stuff. i'm not even sure about what some of the kernel params I have even do.

[uOpt]

i'm not even sure about what some of the kernel params I have even do.

Nobody does

Generally most of the parameters floating around in guides are useless or do nothing.

Why don't you post those you have?

[audiojunkie]

i'm not even sure about what some of the kernel params I have even do.

Nobody does

Generally most of the parameters floating around in guides are useless or do nothing.

Why don't you post those you have?

I disagree. All of the kernel parameters do what they are supposed to do. It’s that people don’t understand them and don’t know how to use them. For example, /threadirqs separates the IRQ threads so that they can be prioritized. However, if the user doesn’t use a script to prioritize those IRQs, there will be no noticeable benefit. A lot of people don’t understand this, and then say that there is no benefit to using that kernel parameter.

Furthermore, if the user is using Pipewire, one must set the soundcard profile to the “Pro Audio” profile, in order to activate the threaded IRQ functionality—otherwise, standard scheduling will be used.

In this single example above, you can see that there are two requirements that must be met to benefit from the /threadirqs kernel parameter. Invariably, someone will not fulfill the requirements to benefit from the kernel parameters, and then claim they don’t work.

[uOpt]

The question remains whether that can be measured.

Another question is whether setting threadirqs in particular is still useful when you have PREEMPT_RT.

[audiojunkie]

Of course it can be measured! If you can get lower latency with fewer xruns with the settings in place than without, then that is an objective measurement. You can even do a loopback test and report actual numbers.

Real time kernels (preempt_rt activated kernels) use and require both. To achieve the same thing on a 6.12+ generic kernel, you must use both the /preempt=full and the /threadirqs kernel parameters. The preempt kernel parameter sets the level of preemption, and the threadirqs separates the irq threads so that they can be prioritized.

The problem that users have, is not understanding how it all goes together, and how each part requires other parts to work.

Edit: It’s like the order of operations in mathematics—if you don’t set everything up ad do it the right way, you’ll come up with different numbers every time. Users who don’t do all of the things required will not achieve the low, xrun-free latencies.