nanook

@subignition @Fediverse_Champion Was directing at threads, don’t want the fediverse to become Farcebook II. I run a Mastodon myself, also Friendica, Misskey, and Hubzilla. Prefer the long format post of Friendica, but don’t want to see any form of centralized moderation because that just leads to centralized indoctrination, ala Farcebook.

Reads to me like, "We want to control the fediverse just like Fuckerberg controls Farcebook, no thanks.

As I expected, it got bounced over to Intel and the basic response was it’s not ready yet.

@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.

@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.

@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.

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.

@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/

@recursive_recursion I am building now.

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.

@Codilingus @strawberry You can pass through your physical audio device then let pipewire on the hypervisor do it.

Yes it is possible and it works just fine.

What I ran in my Linksys WRT54G was DD-WRT, it provided all the normal functionality sans the occasional lockups the stock firmware did, and in addition you could attach to other networks, you could participate in a mesh network, you could increase the transmitter power from 7mw up to as much as 100mw (and this really helped in my environment).

@JoMiran @zShxck That is very nice. I love the way you can toggle between disk space usage and disk I/O usage. Here is a btop of the machine that friendica.eskimo.com is running on:

woshub.com/how-to-repair-uefi-…

@AmosBurton_ThatGuy Yes you can, but I’ve not been using Windows frequently enough to remember how, but if you google re-install windows boot block I believe you can find instructions.

@AmosBurton_ThatGuy Ok, Catchy is based upon Arch, and I’m not sure how you can tell grub on arch how to look on other drives for bootable OS’s. In Ubuntu it’s an argument in /etc/default/grub, but arch it is entirely different and I’ve not run multiple OS’s on it. But with Ubuntu there is a grub argument that says to look on other drives for bootable OS’s and you need to enable that for it to find OS’s on other drives. There must be something similar in CatchyOS, but since I haven’t played with it, and when I was using Arch it was the ONLY OS, I don’t know where to find that. Alternately, you could just switch boot drives in BIOS, or hold F8 after a reboot to select the Windows drive. I do understand though that it is a lot more convenient to have it in the boot menu, unfortunately I haven’t any experience with Catchy or even Arch with multiple OS’s so can’t help with that.

First, which drive is your boot drive?