Real-Time Patches Updated Against The Linux 6.8 Kernel

[phoronix]

Phoronix: Real-Time Patches Updated Against The Linux 6.8 Kernel

It's 2024 and sadly the real-time (RT) patches still have yet to be mainlined for the Linux kernel. At least though the out-of-tree patches continue to be quickly re-based and decrease in size over time... Out today is the Linux v6.8-rc1-rt1 patches for bringing the real-time support against the in-development Linux 6.8 kernel...

https://www.phoronix.com/news/Linux-6.8-rc1-Real-Time

[caligula]

Damn, still almost 100 patches left.

[kiffmet]

RT kernels are not meant/needed for gamers. I'll just leave this here, as there seems to be some confusion around the topic.

[varikonniemi]

Damn, still almost 100 patches left.

But aren't they mainly related to this one area of printk ? So indeed things should be very close to have mainline Linux be RT

[ayumu]

RT kernels are not meant/needed for gamers. I'll just leave this here, as there seems to be some confusion around the topic.

Not "particularly" needed by gamers, but actually required for any desktop/laptop/workstation use.

Linux will happily have peaks of 20+ ms of scheduler latency w/o RT patchset. This is barely tolerable in server scenarios, and unacceptable for interactive use.

This can be trivially verified by running `cyclictest` from `rt-tests` for a while.

[smitty3268]

Not "particularly" needed by gamers, but actually required for any desktop/laptop/workstation use.

Linux will happily have peaks of 20+ ms of scheduler latency w/o RT patchset. This is barely tolerable in server scenarios, and unacceptable for interactive use.

And yet somehow 99% of the world gets along fine without it.

[caligula]

And yet somehow 99% of the world gets along fine without it.

High end audiophiles suffer from jitter caused by non-realtime scheduling. For instance there's a virtual sound card for Apple devices that provides picosecond accuracy by using a shared clock for everything including the DAC. It's stupid to use 1536 kHz DACs if you can't synchronize the clocks properly. Every audiophile can hear the difference in ABX tests.

[ayumu]

High end audiophiles suffer from jitter caused by non-realtime scheduling. For instance there's a virtual sound card for Apple devices that provides picosecond accuracy by using a shared clock for everything including the DAC. It's stupid to use 1536 kHz DACs if you can't synchronize the clocks properly. Every audiophile can hear the difference in ABX tests.

It's more like... when Linux often has 20ms spikes in scheduling latency, the end result is that large enough buffering is added to get around that.

Which means latency in VoIP calls or in a game's audio, in order to prevent the overruns.

Additionally, with RT patchset, serious pro audio pipelines with very low latencies (<=2ms) are possible. Without, Linux is literally useless for these tasks.

I am hopeful distributions will do the sensible thing (enable it for non-server use cases) once this code is finally upstreamed.

[royce]

20ms audio latency is unnoticeable for anything other than music production tasks. You certainly won't notice it on calls or media or even games.

[archkde]

High end audiophiles suffer from jitter caused by non-realtime scheduling. For instance there's a virtual sound card for Apple devices that provides picosecond accuracy by using a shared clock for everything including the DAC. It's stupid to use 1536 kHz DACs if you can't synchronize the clocks properly. Every audiophile can hear the difference in ABX tests.

Every Linux kernel can do realtime scheduling.