Page 6 of 10

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 8:43 am
by Musicteacher
Hi,
if the dsp load goes backwards this means (as far as I know) that the cpu changes its clock (goes higher), thus the dsp load (in percent) goes down even though the load in xruncounter goes up.
For xruncounter to make any sense you must ensure that your cpu runs at a fixed speed!

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 8:52 am
by lilith
raboof wrote:
lilith wrote:
raboof wrote:
Is the jack processing thread still running with a higher real-time priority than any reaper threads?

(I guess something like "ps ax -T --format uname,pid,lwp,ppid,pri,rtprio,cmd" should help figuring this out, though it'd be good to document this on the wiki somewhere ;) )
What do you mean with "Is the jack processing thread still running with a higher real-time priority than any reaper threads? "? Jack has to run, otherwise I canĀ“t run the xruncounter script.
Indeed obviously Jack is running. What I was asking is: what is the priority of the jack processing thread? And is it higher than the reaper thread?

If non-RT reaper threads have higher priority than the jack processing thread, those reaper threads could prevent the jack processing thread from running, causing xruns.
Ok, I will have a look in the evening. Thanks!

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 8:53 am
by lilith
Musicteacher wrote:Hi,
if the dsp load goes backwards this means (as far as I know) that the cpu changes its clock (goes higher), thus the dsp load (in percent) goes down even though the load in xruncounter goes up.
For xruncounter to make any sense you must ensure that your cpu runs at a fixed speed!
My CPU governor is set to performance:
http://i.imgur.com/Dq8WppL.png

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 1:02 pm
by Musicteacher
cpu governor performance does not need to be the best solution.

performance sets the cpu to the highest turbo-boost speed. Being turbo-boost, this is a clock speed that the cpu cannot hold for a longer time.

I have tested which cpu-speed can be kept with my system for a longer time (using prime95 stress test). I have set my cpu to a fixed value of that speed (there are switches for cpupower for that).

However, this does not explain your values going backward (as far as I understand), so I am clueless.

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 1:38 pm
by raboof
Musicteacher wrote:cpu governor performance does not need to be the best solution.

performance sets the cpu to the highest turbo-boost speed. Being turbo-boost, this is a clock speed that the cpu cannot hold for a longer time.
Thanks a lot for your research in viewtopic.php?f=27&t=19865 ! I wonder if this is hardware-dependent, or that all machines are always unable to sustain a constant clock speed when using the 'performance' governor.
Musicteacher wrote:I have tested which cpu-speed can be kept with my system for a longer time (using prime95 stress test). I have set my cpu to a fixed value of that speed (there are switches for cpupower for that).
Sounds useful, do you have this documented somewhere?

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 2:22 pm
by Musicteacher
Hi,
this is, of course hardware-dependent, but it is usual for modern cpus. You can read that in most hardware-tests. For notebooks, testers usually make a stress test to see how long the highest frequencies can be kept, as this is highly dependent on the power of the cooling system.

The turbo-boost was invented partly because modern cpus are multi-core, but certain applications need one core, only. Most cpus can hold the turbo-boost frequency for a long time if the other cores are idle. This usually is not the case for audio, as this uses multiple cores pretty well.

I have not documented my stress-test. prime95 is a standard benchmark to "torture" your system.

You can download it here:

https://www.mersenne.org/download/

You can watch your cpu-speed with i7z . This tool has the advantage that you can watch the c-states being used, too.

So I let prime95 run for several minutes (with 8 threads to make sure all cores are busy) and took a look at the cpu speed.

I made the effort because I use my laptop for live performances. It is of no use for me if my system can handle, say, 10 tracks with virtual instruments and then, after 20 minutes, I figure out that it can't. I'd rather like to know that in advance (and use other instruments, for instance).

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 5:09 pm
by Jack Winter
Maybe worth trying to disable SMT (hyperthreading) too. Thought it didn't matter for my i7, but recently I've discovered that running normal threads does indeed slow down my sched_fifo (realtime) threads.

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 5:33 pm
by lilith
I'm back home and currently testing again. I wonder(ed) why during the xruncounter test with the new script the CPU load is not evenly distributed across all 4 cores:

Image

Maybe because the audio processing is not parallelised.

Further I have:

@audio - rtprio 98
@audio - memlock unlimited

But xruncounter shows me RT priority of 80%, which is the same like the setting in Cadence. I always thought that the setting in limits.conf has priority. Could this be part of the problem. Until now it looks, starting Reaper now ...

edit: and here are the RT priorities of all threads running while also Reaper is running: https://paste.debian.net/1081218/
Could be that the Carla bridge threads are one problem as they have the same priority as Jack (80%).. Hmmm... :shock:

No, that doesn't seem to be the reason. With a higher priority and running Reaper in idle I still get the first xrun at 50% and it's even worse with 512 samples.

Image

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 6:29 pm
by Jack Winter
lilith wrote:I'm back home and currently testing again. I wonder(ed) why during the xruncounter test with the new script the CPU load is not evenly distributed across all 4 cores:

Maybe because the audio processing is not parallelised.
Yes that's it.
Further I have:

@audio - rtprio 98
@audio - memlock unlimited

But xruncounter shows me RT priority of 80%, which is the same like the setting in Cadence. I always thought that the setting in limits.conf has priority. Could this be part of the problem. Until now it looks, starting Reaper now ...
No limits.conf configures the max value that you may use. The max is 99, but there are some threads running there that it's probably best to not interfere with.
edit: and here are the RT priorities of all threads running while also Reaper is running: https://paste.debian.net/1081218/
Could be that the Carla bridge threads are one problem as they have the same priority as Jack (80%).. Hmmm... :shock:

No, that doesn't seem to be the reason. With a higher priority and running Reaper in idle I still get the first xrun at 50% and it's even worse with 512 samples.
To me it looks ok, jack at 80, reaper at 75/73 and xruncounter at 75. What I don't see is at what priority you have set your soundcard interrupt? Also I don't know what carla-bridge is doing, but it appears that you tried disabling that with no change. Give disabling SMT (hyperthreading) a try. Not sure if irqbalance is something you need, or what impact it might have.

Reaper can accesses /dev/cpu_dma_latency if you configure it to. This allows you to disable power saving while reaper is running. Try setting it to 0 or maybe 10, just keep an eye on the cpu temps as they will go up. If it's not writable on your system, you can temporarily make it so with "sudo chown username:username /dev/cpu_dma_latency". This as an alternative to changing power governor.

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 7:09 pm
by lilith
I disabled the IRQbalance as explained here and I get the same (bad) result.

https://access.redhat.com/documentation ... ss_binding

However I observed slightly lower CPU usage in the past without IRQ balance (on the order of - ~2%). Mid of November I was working on the Reaper project with the stock kernel and 512 samples and it played fine. Don't know where these issues come from now. I look for the soundcard priority and reset my interface.

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 7:25 pm
by merlyn
lilith wrote:I wonder(ed) why during the xruncounter test with the new script the CPU load is not evenly distributed across all 4 cores:
tramp has added quite a lot. Thanks tramp! The default is a single core test. To get a multi-core test use

Code: Select all

./xruncounter -m

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 7:31 pm
by lilith
merlyn wrote:
lilith wrote:I wonder(ed) why during the xruncounter test with the new script the CPU load is not evenly distributed across all 4 cores:
tramp has added quite a lot. Thanks tramp! The default is a single core test. To get a multi-core test use

Code: Select all

./xruncounter -m
With the -m option the first xrun appears also at around 50%.

One thing is for sure: When I scroll in Chromium or Firefox the xruns increase a lot! I've written that once, but how can this be or what of Firefox or Chromium can Interfere with the audio processing?

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 7:37 pm
by merlyn
I remember you had a good setup. Has something happened recently that has made performance worse?

One thing is : why is your playback device 'loopback'?

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 7:43 pm
by lilith
merlyn wrote:I remember you had a good setup. Has something happened recently that has made performance worse?

One thing is : why is your playback device 'loopback'?
Not really. Just one thing came into my mind: The reaper project uses only the Cadmium synth. I could be that I use a different plugin version compared to november where the CPU load is higher. I'll check that. When opening chromium, the xruns shoot up, but also the CPU load in Jack reaches >80% (spikes likely >95).

Good question why it's called loopback. My settings look like this:

Image

Re: Standard test needed to benchmark XRUNs

Posted: Thu May 02, 2019 9:39 pm
by lilith
I was looking for the interface priority again , but I don't get any PID number when using pgrep:

Code: Select all

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       
  0:         19          0          0          0  IR-IO-APIC   2-edge      timer
  1:          2          0          0          0  IR-IO-APIC   1-edge      i8042
  8:          1          0          0          0  IR-IO-APIC   8-edge      rtc0
  9:          4          0          0          0  IR-IO-APIC   9-fasteoi   acpi
 12:          4          0          0          0  IR-IO-APIC  12-edge      i8042
 16:         25          0          0          0  IR-IO-APIC  16-fasteoi   ehci_hcd:usb1
 18:          0          0          0          0  IR-IO-APIC  18-fasteoi   i801_smbus
 23:         29          0          0          0  IR-IO-APIC  23-fasteoi   ehci_hcd:usb2
 24:          0          0          0          0  DMAR-MSI   0-edge      dmar0
 25:          0          0          0          0  DMAR-MSI   1-edge      dmar1
 26:         23        418    1023474          0  IR-PCI-MSI 1048576-edge      enp2s0
 27:          0  119358762          0     331001  IR-PCI-MSI 327680-edge      xhci_hcd
 28:      14853          0      12417     137082  IR-PCI-MSI 512000-edge      ahci[0000:00:1f.2]
 29:        719      24487     193445      89876  IR-PCI-MSI 1572864-edge      xhci_hcd
 30:         14          0          0          0  IR-PCI-MSI 360448-edge      mei_me
 31:        622          0          0          0  IR-PCI-MSI 442368-edge      snd_hda_intel:card2
 32:        639    1571350          0          0  IR-PCI-MSI 32768-edge      i915
 33:         67          0          0          0  IR-PCI-MSI 49152-edge      snd_hda_intel:card0
NMI:        539        577        533        510   Non-maskable interrupts
LOC:   56580692   55989093   54896584   57641044   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:        539        577        533        510   Performance monitoring interrupts
IWI:          5          0          0          0   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:    5813381    6994945    4736909    4502349   Rescheduling interrupts
CAL:    1845074    1910720    1668071    1701466   Function call interrupts
TLB:     629552     661927     642250     665107   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
DFR:          0          0          0          0   Deferred Error APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:         53         53         53         53   Machine check polls
ERR:          0
MIS:          0
PIN:          0          0          0          0   Posted-interrupt notification event
PIW:          0          0          0          0   Posted-interrupt wakeup event
now pgrep IRQ/29 gives me nothing.

Code: Select all

marco@fox:~$ pgrep IRQ/29
marco@fox:~$