The neglect for latency in current popular systems such as Linux sickens me.
I suggest experimenting with cyclictest from rt-tests. On all hardware I've tried, I get 30ms+ peaks after running it on the background for not even very long. I can't comprehend how anybody could find this acceptable.
I do run linux-rt for this reason. Then again, while linux-rt provides the tools to make latency reasonable, the rest of the system hardly does use them.
As we move from the likes of Linux to better architected systems, potentially based on seL4, I do hope the responsiveness will return to sanity. Until then, I'll have to keep going back to my Amiga hardware as cope mechanism.
The jump in rhel from 6 to 7 basically made it incredibly hard to tune Linux for very low latency performance requirements. Fairly simple on 6 but 7 made it very difficult. There are lots of tools available, nohz etc, but it doesn't help much. Primary core on each numa node is also loaded with kernel threads causing huge amounts of jitter.
Basically everything is tuned for running web apps with loads of procs for people who don't really care about latency of 100s of millis.
Why would a real-time OS help at all with latency? All RT means is that the latency can be reliably upper-bounded (but note that that upper bound might be very high/slow), it doesn't mean that the latency will be reduced. Real-time OSs aren't faster.
linux-rt is a patchset that changes the behavior of linux to increase the number of places where preemption can occur (among other things).
Doing this decreases certain types of latency in certain situations. As an example, it tries to have interrupts disabled less frequently and for shorter intervals, and uses mutexes instead of spinlocks.
As a result, using linux-rt can provide a lower latency experience compared plain linux.
Ah, that's fair enough, but it isn't 'real time', which is the thing I was assuming from the 'RT' in the name. Perhaps linux-ll would be a better name, for 'low latency'. RT just confuses what it is trying to do.
It is trying to make the linux kernel more real time capable. Having periods of time where preemption isn't enabled (due to having interrupts disabled, etc) results in more variation in when tasks are scheduled, including real time tasks.
The reality is that "real time" as a definition covers many "features" and design choices because many ducks need to be in a row for real time tasks to run properly. Decreasing variation in the scheduling of (real time) tasks is one of those items.
As a result, it's entirely reasonable to call "linux-rt" "linux-rt".
Is extremely desirable. Those multi-ms peaks of latency Linux has are the ones that cause audio cuts and perceived hiccups.
Of course it doesn't matter perceptually if the average is 1µs or 5µs. It's all about the peaks, and keeping them bounded enough so that latency does never cross the perceptual threshold.
But none of the apps they would be running (their browser, in this specific case) are RT. So if the application isn't asking for a hard limit on latency, they aren't going to get anything different on a RT OS.
I suggest experimenting with cyclictest from rt-tests. On all hardware I've tried, I get 30ms+ peaks after running it on the background for not even very long. I can't comprehend how anybody could find this acceptable.
I do run linux-rt for this reason. Then again, while linux-rt provides the tools to make latency reasonable, the rest of the system hardly does use them.
As we move from the likes of Linux to better architected systems, potentially based on seL4, I do hope the responsiveness will return to sanity. Until then, I'll have to keep going back to my Amiga hardware as cope mechanism.