Real-Time "PREEMPT_RT" Support Merged For Linux 6.12

[F.Ultra]

the rt kernel gives you precise time guarantees, thats what it does.

no RT, no "precise 96kHz data flow", because the timing is non deterministic. RT = deterministic timing = accurate handling of time sensitive samples.

You should look into what the RT stuff is doing and how it works, it sounds like you dont actually know what it means.

This seems like a good summary
https://www.youtube.com/watch?v=7hwoJanE5-U

No it doesn't because even with all the patches, the kernel does not turn into a hard real-time kernel (heck even the video you linked explains this so did you even watch it?). What the PREMPT_RT patches does is that they make the kernel fully preemptive so that a task with a higher priority can run if triggered even if the kernel is currently running on the core (without the patch the kernel can only be paused at specific exit points).

What you do when you instead isolate some cores is that you fully remove the kernel from those cores, aka your thread will always be running on it, and will never be interrupted -> latency guarantees that are orders of magnitude lower than what PREMPT_RT can achieve.

[mSparks]

the kernel does not turn into a hard real-time kernel

what use would crashing the entire OS if sometimes it samples at 95kHz be?

What the PREMPT_RT patches does is that they make the kernel fully preemptive so that a task with a higher priority can run if triggered

exactly?
i.e. you can mark a task as "run this task at exactly 96kHz".
you cannot do that on a kernel without prempt_rt, sometimes a task will block taking upwards of 50ms or more (e.g. during heavy garbage collection or flushing data to/from disk), for audio you literally hear that as squeals pops and thumps. for motion tracking - such as that used by monado and Horizon OS - where you need stable sampling of accelerometers- it throws out the tracking (which is why they already use it)

[F.Ultra]

what use would crashing the entire OS if sometimes it samples at 95kHz be?

You do understand that this is just a joke done by the presenter when trying to paint a picture of what the consequences of not reaching a hard requirement would be right?p

i.e. you can mark a task as "run this task at exactly 96kHz".
you cannot do that on a kernel without prempt_rt, sometimes a task will block taking upwards of 50ms or more (e.g. during heavy garbage collection or flushing data to/from disk), for audio you literally hear that as squeals pops and thumps. for motion tracking - such as that used by monado and Horizon OS - where you need stable sampling of accelerometers- it throws out the tracking (which is why they already use it)

If your task runs on an isolated core you will not be blocked ever, hence why I mention that as far superior if you really want deterministic latency. With PREEMPT_RT you will still be blocked (you are still competing with kernel threads and irq:s), just that the blocking will be far smaller than on the non-preempt version and the 10.42µs max deadline for a 96kHz task is AFAIK above the threshold of what PREEMPT_RT can achieve on most systems (on an isolated core [without preempt_rt], you can get down to 10ns), but don't trust me, run e.g cyclictest yourself on various configurations.

[mSparks]

You do understand that this is just a joke done by the presenter when trying to paint a picture of what the consequences of not reaching a hard requirement would be right?p

Its not a "joke" hard realtime throws a kernel panic if it breaches the scehduling requirements, soft realtime doesn't.

If your task runs on an isolated core you will not be blocked ever

Not true, that task still has to make use of memory,cache and disk access - shared, non deterministic resources that can block for milliseconds if they are in use by other cores.

With PREEMPT_RT you will still be blocked

Nope, because the task priority "steals" the resources off the task that is using them, stopping them blocking it.

[F.Ultra]

Its not a "joke" hard realtime throws a kernel panic if it breaches the scehduling requirements, soft realtime doesn't.

No it doesn't. I have worked with several hard realtime kernels including qnx, RTLinux and vxWorks. None of them throws a kernel panic on scheduling breach. Not to say that you cannot do that by adding an optional watchdog, but that you can do with generic Linux as well.

Not true, that task still has to make use of memory,cache and disk access - shared, non deterministic resources that can block for milliseconds if they are in use by other cores.

And those will continue to be blocked just as much in a fully preemptive kernel, what PREMPT_RT can do is to preempt another task if they are blocking your access to the file due to a lock, but when we are talking about ms long delays from file access we are talking about the actual hw being saturated, there are no outstanding locks. This is why one never does IO in a RT thread (I'm starting to suspect that you haven't developed any RT applications or have very limited experience doing that). Memory and cache are only blocked at the hw level (and the timeframe is nanosecons anyway) and this is not changed with a fully preemtive kernel, you would need special hardware for this.

Nope, because the task priority "steals" the resources off the task that is using them, stopping them blocking it.

There are no hw supervisor running, so the transfer of control from the kernel/other-application to your application will still require code to run, that is what I meant with blocking, aka you are still going to be blocked for some cpu cycles. This as compared with an isolated core where you are never blocked since nothing else runs there.

You are still also facing the problem that your average latency with PREMPT_RT is most likely ways above the needs for 96kHz (on my 5800x3D it surely is at around 50µs vs the needed 10µs), again specialty hw is needed to get that low latency.

[mSparks]

This is why one never does IO in a RT thread (I'm starting to suspect that you haven't developed any RT applications or have very limited experience doing that).

lol, yeah right, a thread that doesn't communicate with the outside world, just sits there burning watts.

omfg.

I'm starting to think you are just copy pasting from a really bad locally running language model, but I doubt it because even that would do a better job than this.

[F.Ultra]

lol, yeah right, a thread that doesn't communicate with the outside world, just sits there burning watts.

omfg.

I'm starting to think you are just copy pasting from a really bad locally running language model, but I doubt it because even that would do a better job than this.

That is not at all what I said, and that you thought I did is quite telling.

[mSparks]

That is not at all what I said, and that you thought I did is quite telling.

So how do you propose a thread communicates with the outside world using something other than input and output? teletransmutation?

[F.Ultra]

So how do you propose a thread communicates with the outside world using something other than input and output? teletransmutation?

So you really believe that IO is the only way to communicate with a thread? Ever heard of shared memory, stacks or queues?

Ofc if your RT thread is say tasked with processing network data then yes it have to read that from a NIC (getting it via a non RT thread is ofc not an option then since that would defeat the whole purpose), in that case we also isolate the NIC, aka that NIC would be dedicated to the RT traffic and never to be shared with other processes or traffic. But any other second hand IO (like logging, or storing some result where latency is not key) is done by transferring that data to another non RT thread and let that thread handle the IO. And this includes talking to say a GUI (here is a common issue with many audio applications in where they are completely wrong built for RT since they tend to communicate with the GUI from the RT parts).

The main issue here is that all IO introduces non deterministic latency that is not preemtable since the latency is not due to other processes/thread/kernel holding any locks, which is we (aka where I work) have to isolate as much as possible (since we work at the nanosecond scale [low latency stock trading]) where the OS is basically only involved for the non RT parts (aka even networking is done in userspace to completely bypass the kernel).

The current setup that I'm working with are a fleet of dual socket servers with Epyc 9174F (the higher freq variant to lower the single core latency) where one cpu is completely isolated to run 8 read-side threads and 8 write-side threads while the second cpu is there to give the OS and non rt applications 16 threads to play with.

This is not my saying that PREEMPT_RT is worthless or wrong, I have just been saying from the start that isolation gives you much lower latencies and much more control over timing. I'm not entirely sure why you are arguing against that, it should be common knowledge even for people like you who are just using software and not writing it (especially rt software).

[mSparks]

Ever heard of memory, stacks or queues

I've never heard of accessing them with anything other than via IO over the data bus. So what magical mechansim are you using to access them from the RT thread that doesn't use the only physical connection between them?

You should look into projects like

https://www.freertos.org/

You sound overly confident in isolation, the sources of non determinism that mess up your timing run much deeper than you seem to realise, and this is a well defined subject with significant research for stuff like AIRINC429/653 and MIL-STD-1553 which you don't seem to be familiar with.