- cross-posted to:
- linux@lemmy.zip
- foss@infosec.pub
- cross-posted to:
- linux@lemmy.zip
- foss@infosec.pub
cross-posted from: https://lemmy.zip/post/26533086
Linux kernel 6.12 is one of the most significant releases of the year, delivering a feature nearly 20 years in the making: true real-time computing.
You must log in or # to comment.
Is there any work being to certify specific kernel versions for safety
for you
The 6.12 kernel UHD630 graphics worked when not compiled for realtime but just voluntary preemption. So I have filed Bug 219510. I suspect the kernel team will refer me to Intel since they actually maintain this driver, then Intel will say well it worked when the kernel people didn’t hack it for real time and it will end up going nowhere but time will tell. Without a working display, I can’t really test KVM/QEMU so will have to wait for action on this bug.
As I understand it, most kernel operations can’t be interrupted (i.e., they’re non-preemptible). But PREEMPT_RT allows high-priority tasks to interrupt lower-priority ones near-instantly. For specific types of tasks this improves response times and thus performance.
I never looked into the details of realtime Kernel. I know it is or was used for professional realtime audio mixing and recording and such. Besides that, if this improves response times, would gaming benefit from this? What are downsides for using a realtime Kernel for gaming?
Realtime doesn’t necessarily mean low latency, it means consistent latency.
So if the latency from and input takes 1s, that is realtime, as long as its always 1s.
Typically for gaming you want the lowest latency possible, and at least historically, that meant not realtime.
Edit: Some examples with made up numbers:
Airbag: you want an airbag to go off EVERY time, and if that means it takes 10ms, thats usually OK. RT guarantees that your airbag will go off 10ms after a crash every time.
Games: you want your inputs handled ASAP, ideally <5ms, but if one or two happen after 100ms, you’ll likely not notice. If you enable RT, maybe all your inputs get handled after 10ms consistently, which ends up feeling sluggish.
Unless you know you need RT, you probably dont actually want it.
Realtime doesn’t necessarily mean low latency, it means consistent latency.
This is such a critical distinction which can be counter-intuitive. In this case, their game may run slower, they just won’t get lags resulting from local resource contention. And even that statement has caveats.
One of the biggest difference between self-taught developers and ones with CS degrees is that the ones with degrees usually understand a lot of important theory, such as O(1) means constant time, not necessarily fast time.
Games: you want your inputs handled ASAP, ideally <5ms, but if one or two happen after 100ms, you’ll likely not notice. If you enable RT, maybe all your inputs get handled after 10ms consistently, which ends up feeling sluggish.
Actually I think its the other way for gaming: If you have consistent input delay, it will not feel sluggish. Same why consistent 30 fps feels better than varying 31 to 39 fps. Similar for gaming, especially if you play speedrun or 1vs1 fighting games, you would want to have consistent delay. However, if that adds too much delay its probably counterproductive. But for single player games, a consistent delay is the opposite of sluggish.
At low numbers, it doesnt matter. If you exqgerate the numbers the effect is more clear.
Eg. if the latency was 100ms, it would feel your movments are behind by 100ms, which would be unplayable.
But if you had a typical latency of 10ms, with rare spikes to 1s, the spikes would be considered lag, and annoying, but most of the time its good and playable.
@CameronDev @thingsiplay I refer you to this: https://www.pubnub.com/blog/how-fast-is-realtime-human-perception-and-technology/
That said, we did an experiment in a physics class many years ago where by there was a beeper and an electromagnet that were powered by the same source. The electromagnet held a yard stick in place. When the beeper went off we were supposed to push a button in response. The button stopped the fall of the yardstick. Then by calculating how far the yard stick fell using the 32m/s^2 speed of gravitational acceleration we calculated how long response was, average was about 200ms, I responsed in 30ms, however this only works for me for auditory queues, visual is more delayed for me, and I can’t detect any change in under 20ms and just barely at that, let alone respond to it. But what I learned in that class was that reaction times varied individual to individual by a factor of about ten, so what is true for one person may not be for another.
Yeah it definitely varies per person, and I think you can even train for it somewhat.
I used to play a lot of guitar hero, and I think this improved my visual “latency” a lot, to the point where I could definitely tell when something was visually 5-10ms out of sync (in the case of guitar hero, when you strum the bar vs when the note lines up with the strikeline).
@thingsiplay @CameronDev I agree consistent delay is better because your brain automatically adjusts for it, it has several hundred milliseconds of delay built-in, but inconsistent sub-millisecond delay is not going to be humanly detectable.
@CameronDev @thingsiplay As I previously stated, a normal preemptive kernel will generally provide <1ms latency. RT does provide the possibility of lower latency and not inconsistent as you suggest unless you are resource saturated.
When I last looked into it, many years ago, RT definitely did negatively impact average latency. It was slower, but consistent. Has that actually changed?
@CameronDev I never applied the real time patch before it was integrated in 6.12, so I have no previous experience to compare to. And with 6.12, I can only go by documentation at present because the realtime configuration breaks my graphics so I have no display. But I have worked in audio studios in the past where they used it and claimed it helped. I can only take their word, but I did mention the tradeoffs earlier, if you do more context switching it is going to eat more resources, so if you are resource saturated it’s going to slow you down instead of speed you up. I am anxious for the driver issue to be resolved so I can try for myself on my hardware. I am particularly curious to see how my i9-10980xe (18 core / 36 thread) machine will respond to it. That is the machine this friendica runs on so I really need to know it’s going to be stable before I even try it, but that machine does have nvidia rather than UHD630 graphics so may work.
@thingsiplay @recursive_recursion
With respect to gaming, the answer is a definite “maybe”. Here is the thing with a real time kernel, context switching is expensive, and especially so when going between kernel and userland mode. This is because you have to save/restore all the registers on the stack so there are a lot of memory cycles involved in a context switch. A realtime kernel increases context switching a LOT so you’re going to eat more CPU than you otherwise would but on the other hand, critical things will get attended to in a more timely manner. So whether the latency or the overall computational efficiency is more important will make the difference in gaming. Also to some degree hardware, most games will only use 4 cores or so, a few more than that but most only about 4, so if you’ve got an 18 core machine, you have plenty of core for the extra kernel overhead, it is more likely to benefit than if you’re on a 4-core machine with all the cores already saturated.
@thingsiplay @lemmy.ca A normal preemptive kernel with 1000HZ tick will usually provide sub 1ms latency which for most audio is adequate.
That said, I just built 6.12.0 and the display drivers for UHD630 graphics appear to be broken, at least when compiled for realtime. I am going to go re-compile it normal pre-emptive as I normally do and see if it has the same issues. It booted, and got up to the point where it executed /etc/rc.local because it turned on my keyboard leds, but the screen never displayed.
If you wish to try I have built for both debian and redhat based systems, you can download the install packages, .deb or .rpm at:
https://www.eskimo.com/kernel/linux-6.12-tickless/realtime/The issues are mainly under high CPU load. A RT kernel will continue to maintain low latency without xruns but a normal kernel may not. The compromise option is full preemption which generally does a good job but doesn’t have the issues with throughput that can occur with a RT kernel.
Although maybe you meant full when you indicated a preemptive kernel (voluntary preemption is still the default I believe but it’s kernel dependent).
I’ve avoided RT thus far because it was incompatible with KVM/QEMU. Am curious if this is still the case. Guess I can compile and install on my workstation and see
if my virtual machines still work.I tested it with 6.11 and the performance was kind of bad but it could have been a one off. I’m generally happy with full preemption though.
I’ve avoided RT thus far because it was incompatible with KVM/QEMU. Am curious if this is still the case.
I didn’t even realize that this was a known problem.
Guess I can compile and install on my workstation and see if my virtual machines still work.
I’d appreciate it if you could also let me know how it goes! I’m hoping that it just_works.™️ on your end🫡
I’m still a bit of a Linux noob but when I updated my kernel to the latest a few months ago it broke VMware and I couldn’t get it to work again . I don’t remember the exact errors at this point but I determined it was definitely a kernel issue . I’m using Ubuntu for now btw .
@recursive_recursion I am building now.
