normal Linux kernels with threadirqs vs RT patchset
Moderators: MattKingUSA, khz
normal Linux kernels with threadirqs vs RT patchset
What are your experiences using normal Linux kernels with the threadirqs parameter versus realtime patched kernels? Is there a significant difference in the minimum latency you can use? Any differences in reliability of the audio stream (clicks and pops)? Any difference in overall system stability? I've been using the normal Fedora kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.
I'm considering switching Crossfade GNU/Linux to the normal Fedora kernel with the threadirqs parameter because it gets updated more frequently and is signed with a Microsoft approved key so it works with Secure Boot enabled.
I'm considering switching Crossfade GNU/Linux to the normal Fedora kernel with the threadirqs parameter because it gets updated more frequently and is signed with a Microsoft approved key so it works with Secure Boot enabled.
Re: normal Linux kernels with threadirqs vs RT patchset
I'm using kernel with threadirqs and must say it's working, with kernel 4.0 I have got few xruns ( I have used wifi and all stuff), now with kernel 4.1 system looks more stable.
artek
artek
Re: normal Linux kernels with threadirqs vs RT patchset
I have the same experience (except I don't use Fedora). The RT kernel was definitely more pain than gain.Be. wrote:I've been using the normal […] kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.
Now I'm using a manually configured Gentoo kernel (no fancy patches, pretty close to vanilla) and it works like a charm.
Please, avoid some common spelling errors:
http://theoatmeal.com/comics/misspelling
http://theoatmeal.com/comics/misspelling
-
- Established Member
- Posts: 2347
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 466 times
Re: normal Linux kernels with threadirqs vs RT patchset
I'm using the rt-kernel versions now exclusively for more then 9 years. Truly, some versions of them gime trouble, and then I stay with the latest working version. But, to be honest, I've got the same trouble with vanilla kernels of this versions, which I installed for comparison. I'm never ever experience "instability" problems with rt-kernels which aren't introduced by kernel.org vanilla kernel. Well, sure, it happens, but, it's negotiable and get solved real, real fast.artek wrote:I'm using kernel with threadirqs and must say it's working, with kernel 4.0 I have got few xruns ( I have used wifi and all stuff), now with kernel 4.1 system looks more stable.
However, I can't comment on any performance boost, as I never used vanilla kernel for more then compare stability.
On the road again.
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: normal Linux kernels with threadirqs vs RT patchset
rt-kernel here as well. Sticking at the moment with 3.18-RT on Arch which is considered stable/LTS, but the difference is indeed not as dramatic as it used to be.
I plan to do another comparison with 4.1 (I found also that 4.0, rt or vanilla was more pain than gain).
I plan to do another comparison with 4.1 (I found also that 4.0, rt or vanilla was more pain than gain).
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: normal Linux kernels with threadirqs vs RT patchset
Update: I just gave a try at the stock Arch kernel (4.1.6 at the time of writing) with threadirqs + rtirq, and it's perfectly capable of reaching low latencies (64*3 period @96K with a F. Scarlett 2i2). Still got some xruns, but I was quite surprised...
So I'd say the difference between stock and RT is not really noticeable with 4.1.x.
This being said, I still get a slightly better performance out of an older 3.18-RT kernel than any 4.X, RT or not.
Hope this helps,
LX
So I'd say the difference between stock and RT is not really noticeable with 4.1.x.
This being said, I still get a slightly better performance out of an older 3.18-RT kernel than any 4.X, RT or not.
Hope this helps,
LX
- English Guy
- Established Member
- Posts: 525
- Joined: Wed Oct 17, 2012 7:28 pm
- Location: England
- Has thanked: 8 times
- Been thanked: 7 times
Re: normal Linux kernels with threadirqs vs RT patchset
I have been told the rt is more important with usb devices; might be worth bearing that in mind with testing. What system says the latency is and the xruns you get in certain scenarios are two different things.
Re: normal Linux kernels with threadirqs vs RT patchset
With my actual setup, Compaq Presario CQ61 + ArchBang + Focusrite Scarlett 2i4, I can hardly do stuff without RT (RT LTS from Archaudio repos). However, my laptop has always been a pain with USB audio devices...
-
- Established Member
- Posts: 897
- Joined: Thu Sep 11, 2014 3:04 pm
- Has thanked: 71 times
- Been thanked: 64 times
Re: normal Linux kernels with threadirqs vs RT patchset
My experience with "normal" Linux kernels is that they don't work well for audio either with or without tricks & tuning like threadirqs. Particularly not if you intend to use low-latency soundcard settings in jack. It'll xrun like a mf.Be. wrote:What are your experiences using normal Linux kernels with the threadirqs parameter versus realtime patched kernels? Is there a significant difference in the minimum latency you can use? Any differences in reliability of the audio stream (clicks and pops)? Any difference in overall system stability? I've been using the normal Fedora kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.
I'm considering switching Crossfade GNU/Linux to the normal Fedora kernel with the threadirqs parameter because it gets updated more frequently and is signed with a Microsoft approved key so it works with Secure Boot enabled.
The only real solution I've found (perhaps mileage varies for others) is through the use of a PREEMPT (PREEMPT, 1000Hz) or RT Kernel. None of the other fixes or solutions quite managed to work for me, even if they may / may not be somewhat beneficial under particular conditions. (I think Ubuntu provides a kind PREEMPT kernel called "low latency".... I prefer to compile my own).
Another source of xruns (in my case) was opensource nouveau drivers, particularly when using a webbrowser. (Yes I know... supposedly one shouldn't use a browser whilst doing audio but it xruns a hell of a lot less with nVidia drivers)
Certain audio geared distros probably already contain RT or PREEMPT/Low Latency kernels. If RT Kernels don't work for you (and they can sometimes be finicky to get to work problemfree) then compiling a PREEMPT kernel would be the other option. That's what I use most of the time.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
Re: normal Linux kernels with threadirqs vs RT patchset
I did some changes here and I *think* I am using kernel with threadirqs now. I'm not sure. How do I find out?
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: normal Linux kernels with threadirqs vs RT patchset
There's a boot parameter to activate, so you would probably know it if it was enabled.
I don't remember very well but you may also see the threads in a task manager/top/htop/whatever (or with rtirq.sh status),
With GRUB that would look something like:
I don't remember very well but you may also see the threads in a task manager/top/htop/whatever (or with rtirq.sh status),
With GRUB that would look something like:
To experience any tangible benefit for audio work, I assume you need also rtirq (http://alsa.opensrc.org/Rtirq) and to tweak the default configuration for your particular soundcard type.GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs"
Re: normal Linux kernels with threadirqs vs RT patchset
I followed these instructions exactly:
https://wiki.ubuntu.com/UbuntuStudio/rtirq
But then update-grub failed at first for slightly complicated reasons... then it updated, but I don't know if the changes were applied. You never know with computers.
https://wiki.ubuntu.com/UbuntuStudio/rtirq
But then update-grub failed at first for slightly complicated reasons... then it updated, but I don't know if the changes were applied. You never know with computers.
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: normal Linux kernels with threadirqs vs RT patchset
update-grub overwrites /boot/grub/grub.cfg, so you could first check if threadirqs made it there (which would indicate that the command was successful).
or, on the boot menu, just press "e" to see what is appended to the boot parameters.
Once booted, the simplest is probably to read the output of rtirq status
Or you can run the command below from http://wiki.linuxaudio.org/wiki/system_configuration
This should tell you if the kernel you're running is preemptible and has irq threading activated.
or, on the boot menu, just press "e" to see what is appended to the boot parameters.
Once booted, the simplest is probably to read the output of rtirq status
Or you can run the command below from http://wiki.linuxaudio.org/wiki/system_configuration
Code: Select all
grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT=y" /boot/config-`uname -r`
Re: normal Linux kernels with threadirqs vs RT patchset
You sound quite knowledgeable about this so maybe you can solve the "complicated" part of my uncertainty.
I edited /etc/default/grub and updated grub. However, grub initially complained that it could not find /boot/grub/grub.cfg. Upon inspection, I found that I didn't have the /boot/grub directory. I had /boot/boot/grub. Weird, isn't it?
I have /boot mounted on its own partition. That probably explains it, but I'm not sure if and how.
Well, I copied /boot/boot/grub over to /boot/grub and update-grub worked, but... How have I been booting all this time? Which grub configuration has been read at boot time for the last few months, after I migrated to Debian Jessie?
I guess I'll have to press e on the grub boot screen to be sure. I can't reboot right now, I am working and have too much going on.
I edited /etc/default/grub and updated grub. However, grub initially complained that it could not find /boot/grub/grub.cfg. Upon inspection, I found that I didn't have the /boot/grub directory. I had /boot/boot/grub. Weird, isn't it?
I have /boot mounted on its own partition. That probably explains it, but I'm not sure if and how.
Well, I copied /boot/boot/grub over to /boot/grub and update-grub worked, but... How have I been booting all this time? Which grub configuration has been read at boot time for the last few months, after I migrated to Debian Jessie?
I tried it and got CONFIG_IRQ_FORCED_THREADING=y, but the question remains: does it matter to a system that is probably booting off /boot/boot/grub?gimmeapill wrote:Code: Select all
grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT=y" /boot/config-`uname -r`
I guess I'll have to press e on the grub boot screen to be sure. I can't reboot right now, I am working and have too much going on.
Re: normal Linux kernels with threadirqs vs RT patchset
Maybe you have a UEFI system. Do you have /boot/efi?