rtirq and threadirqs performance

[bluebell]

I activated the threadirqs kernel option. rtirq ran fine, "rtirq status" showed meaningful values (priorizing xhci_hcd irqs).

Theoretically this should have made the audio performance (Qtractor, Plugins, audio interface) better but made it worse with my v5 kernel. I had xruns with buffersizes that worked without xruns without threadirqs.

Did I do it wrong?

[Daniele71]

I've threadirqs and preempt=full as kernel options. To be honest I didn't notice great differences but for sure not worst.
Also I use mitigations=off. I don't think you did it wrong, maybe just does not work well on your system.. who knows..

[Loki Harfagr]

Possible problem is that xhci might cover many stuff including disks so you may try to favoritise your audio interface, in a console launch this command:

Code: Select all

watch grep xhci /proc/interrupts

Then in another console or from an audio app do something that would use noticeably your targeted audio interface then check in the console watching the interrupts which one seems to actually move its numbers, eg:

Code: Select all

 129:    1704289          0          0          0  PCI-MSI-0000:00:14.0    0-edge      xhci_hcd
 130:          0  186212494          0          0  PCI-MSIX-0000:07:00.0    0-edge      xhci_hcd
 131:          0          0          0          0  PCI-MSIX-0000:07:00.0    1-edge      xhci_hcd

Then use the Id number in the rtiq.conf file, like:

Code: Select all

RTIRQ_NAME_LIST="130 131 135"

finally restart the rtirq daemon and test again if the xruns situation evolved (hopefully)

[autostatic]

Hi Bluebell, which kernel are you using? How does your /etc/default/rtirq file look like? Which version of rtirq are you using? To which port is your audio interface connected? No other devices on this port? What is the output of /etc/init.d/rtirq status?

[magill]

Rtirq has never made a significant improvement (but I'll definitely try to set it up the way Loki suggests above).

If you are using USB interface, this thread is so worth checking out. The difference it made to me is like no other optimisation I've ever tried; I'm now able to run reaper with helix native, jamstix and ezdrummer at the same time with hardly any xruns at buffer size set at 48. I didn't think it's possible and before I was stuck at 256 for a similar performance.

[bluebell]

Rtirq has never made a significant improvement (but I'll definitely try to set it up the way Loki suggests above).

If you are using USB interface, this thread is so worth checking out. The difference it made to me is like no other optimisation I've ever tried; I'm now able to run reaper with helix native, jamstix and ezdrummer at the same time with hardly any xruns at buffer size set at 48. I didn't think it's possible and before I was stuck at 256 for a similar performance.

Yep, I uses these settings already.

[bluebell]

Hi Bluebell, which kernel are you using? How does your /etc/default/rtirq file look like? Which version of rtirq are you using? To which port is your audio interface connected? No other devices on this port? What is the output of /etc/init.d/rtirq status?

Kernel: 5.8.6 #1 SMP PREEMPT (with drumfix' ua101 replacement for MOTU UltraLite AVB)

/etc/default/rtirq:

Code: Select all

# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"

# Highest priority.
RTIRQ_PRIO_HIGH=90

# Priority decrease step.
RTIRQ_PRIO_DECR=10

# Lowest priority.
RTIRQ_PRIO_LOW=51

# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0

# On kernel configurations that support it,
# which services should be NOT threaded 
# (space separated list).
#RTIRQ_NON_THREADED="rtc snd"

# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
RTIRQ_HIGH_LIST="timer"

rtirq-init from 20150216-1

/etc/init.d/rtirq status:

Code: Select all

  PID CLS RTPRIO  NI PRI %CPU STAT COMMAND	
  140 FF      90   - 130  0.0 S    irq/8-rtc0	
  129 FF      70   - 110  8.1 S    irq/127-xhci_hc	
  130 FF      69   - 109  0.0 S    irq/128-xhci_hc	
  131 FF      68   - 108  0.0 S    irq/129-xhci_hc	
  132 FF      67   - 107  0.0 S    irq/130-xhci_hc	
  133 FF      66   - 106  0.0 S    irq/131-xhci_hc	
  134 FF      65   - 105  0.0 S    irq/132-xhci_hc	
  135 FF      64   - 104  0.0 S    irq/133-xhci_hc	
  136 FF      63   - 103  0.0 S    irq/134-xhci_hc	
  137 FF      62   - 102  0.0 S    irq/135-xhci_hc	
  139 FF      60   - 100  0.0 S    irq/1-i8042	
  138 FF      59   -  99  0.0 S    irq/12-i8042	
  111 FF      50   -  90  0.0 S    irq/9-acpi	
  222 FF      50   -  90  0.0 S    irq/136-ahci[00	
  250 FF      50   -  90  0.1 S    irq/138-i915	
  575 FF      50   -  90  0.0 S    irq/139-mei_me	
 1187 FF      50   -  90  0.0 S    irq/137-enp5s0	
    9 TS       -   0  19  0.2 S    ksoftirqd/0	
   15 TS       -   0  19  0.2 S    ksoftirqd/1	
   20 TS       -   0  19  0.2 S    ksoftirqd/2	
   25 TS       -   0  19  0.2 S    ksoftirqd/3	
   30 TS       -   0  19  0.2 S    ksoftirqd/4	
   35 TS       -   0  19  0.1 S    ksoftirqd/5	
   40 TS       -   0  19  0.1 S    ksoftirqd/6	
   45 TS       -   0  19  0.1 S    ksoftirqd/7	

Interface is connected on a separate USB port, nu USB hub is used.

Looking at the counters from /proc/interrupts it uses IRQ 127.

Looks all good to me but performs worse (with dropouts and xruns) than without threadirqs.

Kernel command line (without threadirqs) is:

Code: Select all

quiet splash mitigations=off acpi_irq_nobalance nowatchdog nohz=off intel_idle.max_cstate=1 usbcore.autosuspend=-1