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 cxYour 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. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
pgpkBXOWiYjFT.pgp
Description: Digitale PGP-Signatur
