Hi Alexander,
Thank you for the pointers.
I will try it out.
--HPS
On 11/18/22 09:18, Alexander Leidinger wrote:
Quoting Hans Petter Selasky <h...@selasky.org> (from Fri, 18 Nov 2022
05:47:58 +0100):
Hi,
I'm doing some work with audio and have noticed some problems with the
ULE scheduler. I have a program that generate audio based on
key-presses. When no keys are pressed, the load is near 0%, but as
soon as you start pressing keys, the load goes maybe to 80% of a CPU
core. This program I run with rtprio 8 xxx. The issue I observe or
hear actually, is that it takes too long until the scheduler grasps
that this program needs it's own CPU core and stops time-sharing the
program. When I however use cpuset -l xxx rtprio 8 yyy everything is
good, and the program outputs realtime audio in-time.
I have something in my mind about ULE not handling idleprio and/or
rtprio correctly, but I have no pointer to a validation of this.
Or is this perhaps a CPU frequency stepping issue?
You could play with
rc.conf (/etc/rc.d/power_profile):
performance_cpu_freq="HIGH"
performance_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx
economy_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx
Your system may provide other Cx possibilities, and ging to a lower
number (e.g. C1) means less power-saving but faster response from the
CPU (I do not expect that this is causing the issue you have).
Any advice on where to look?
Potential sysctl to play with to change "interactivity detection" in ULE:
https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html
Bye,
Alexander.