22 Nov
2014
22 Nov
'14
1:28 p.m.
Recently I updated my 'office' computer, which I often use for experimenting
(I don't try anything new on the DAW) and suddenly I'm getting a *lot* of Xruns
and, apparently, very high CPU loading.
Eventually I found the cause. Going from linux kernel 3.2 to 3.16 :(
This, apparently, does very aggressive CPU frequency scaling. Drop back to 3.2
and all is sweetness and light again.
The question is whether there is a reasonably straightforward way to stop this
behaviour. Doing the usual searches doesn't seem to turn up anything useful.
Any help gratefully appreciated.
I would add that I've double checked that the bios is set for 'performance'.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
22 Nov
22 Nov
1:33 p.m.
On Sat, Nov 22, 2014 at 12:27 PM, Will Godfrey
<willgodfrey(a)musically.me.uk> wrote:
Eventually I found the cause. Going from linux kernel
3.2 to 3.16 :(
This, apparently, does very aggressive CPU frequency scaling. Drop back to 3.2
and all is sweetness and light again.
The question is whether there is a reasonably straightforward way to stop this
behaviour.
You can temporarily disable CPU frequency scaling by running the following:
cpupower frequency-set -g performance
To return to normal "when-needed" CPU frequency scaling (better for
battery / heat)
cpupower frequency-set -g ondemand
This might work too, it "hard-sets" to the lowest CPU speed: generally
switching CPU freq causes the xruns, not the actual slow-setting
itself. Useful for battery performance.
cpupower frequency-set -g powersave
Note that frequency scaling is currently broken on newest -rt kernels
on *old* CPU's. ArchAudio repositories have a hard-coded "performance"
-rt kernel, which sets the default speed to max: thanks JackWinter for
packaging that!
Cheers, -Harry
--
http://www.openavproductions.com
1:37 p.m.
Hi Will,
[..]
Eventually I found the cause. Going from linux kernel
3.2 to 3.16 :(
This, apparently, does very aggressive CPU frequency scaling. Drop back to 3.2
and all is sweetness and light again.
The question is whether there is a reasonably straightforward way to stop this
behaviour. Doing the usual searches doesn't seem to turn up anything useful.
Any help gratefully appreciated.
I would add that I've double checked that the bios is set for 'performance'.
Just a shot in the dark here, but did you try using the "cpufreq-set" tool (in
Debian-based distributions: in package "cpufrequtils) to set the CPU governor?
(As root), do:
# cpufreq-set -g performance
On an older machine, I had Xrun issues sometimes, and this tool helped overcome
it at that time. However, I have never seen the CPU load spikes you mention.
Greetings,
Frank
1:53 p.m.
On Sat, 22 Nov 2014 13:37:20 +0100
Frank Neumann <beachnase(a)web.de> wrote:
Hi Will,
[..]
Thank you both for such a quick response. This solved the problem completely :)
Xruns completely disappeared and qjackctl reading dropped from over 40% to less
than 10%
P.S.
I was running some quite complex yoshi/zyn patches - they can be quite
demanding!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Eventually I found the cause. Going from linux
kernel 3.2 to 3.16 :(
This, apparently, does very aggressive CPU frequency scaling. Drop back to 3.2
and all is sweetness and light again.
The question is whether there is a reasonably straightforward way to stop this
behaviour. Doing the usual searches doesn't seem to turn up anything useful.
Any help gratefully appreciated.
I would add that I've double checked that the bios is set for 'performance'.
Just a shot in the dark here, but did you try using the "cpufreq-set" tool (in
Debian-based distributions: in package "cpufrequtils) to set the CPU governor?
(As root), do:
# cpufreq-set -g performance
On an older machine, I had Xrun issues sometimes, and this tool helped overcome
it at that time. However, I have never seen the CPU load spikes you mention.
Greetings,
Frank 
2:23 p.m.
JFTR neither all distros use the same cpu frequency scaling tool, nor
do distros stay with a tool, they tend to switch from one tool to
another with different distro releases.
What always works is to check and change it without a tool.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
printf performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
>/dev/null
Regards,
Ralf
OT: Nice, the Claws editor by Edit > Auto wrapping disabled allows to
post code without getting line wrapped. Still not as comfortable as
Evolution's editor feature.
3:41 p.m.
On 22 November 2014 at 14:23, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
What always works is to check and change it without a
tool.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
That always was quickly busted, as this path does not exist on my
machine. No cpufreq directory under any of the cpu* dirs. Maybe a
kernel setting? I'm on a 3.14-12-rt9 kernel
4 p.m.
On Sat, 22 Nov 2014 15:40:38 +0100
Arve Barsnes <arve.barsnes(a)gmail.com> wrote:
On 22 November 2014 at 14:23, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Oops! My apologies.
What distro?
Maybe a kernel setting, but it has nothing to do with rt patched 3.14
kernels per se. Is any governor enabled?
[rocketmouse@archlinux ~]$ zgrep CONFIG_CPU_FREQ_GOV /proc/config.gz
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
[rocketmouse@archlinux ~]$ uname -r
3.14.23-rt20-1-rt
Regards,
Ralf
What always works is to check and change it
without a tool.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
That always was quickly busted, as this path does not exist on my
machine. No cpufreq directory under any of the cpu* dirs. Maybe a
kernel setting? I'm on a 3.14-12-rt9 kernel
5:22 p.m.
On 22 November 2014 at 15:53, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Maybe a kernel setting, but it has nothing to do with
rt patched 3.14
kernels per se. Is any governor enabled?
[rocketmouse@archlinux ~]$ zgrep CONFIG_CPU_FREQ_GOV /proc/config.gz
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
[rocketmouse@archlinux ~]$ uname -r
3.14.23-rt20-1-rt
POWERSAVE and CONSERVATIVE was not set, but the others were enabled.
On the other hand I have this:
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
which seems like it could stop this stuff from showing in the fs
Arve
3:46 p.m.
On Sat, 22 Nov 2014, Will Godfrey wrote:
Eventually I found the cause. Going from linux kernel
3.2 to 3.16 :(
This, apparently, does very aggressive CPU frequency scaling. Drop back to 3.2
and all is sweetness and light again.
Frequency scaling does seem to cause problems
The question is whether there is a reasonably
straightforward way to stop this
behaviour. Doing the usual searches doesn't seem to turn up anything useful.
Any help gratefully appreciated.
I would add that I've double checked that the bios is set for 'performance'.
Performance in the bios is probably not the cpu governor. In fact if that
turns "Boost" on, that is bad. I thought I knew the answer to this.... but
looking at this computer (atom based) I am not seeing what I would expect.
First, there is a file in /etc/init.d/ called ondemand. It deals with a
directory:
/sys/devices/system/cpu/cpu0/cpufreq/
(actually a set of directories the cpu0 will also be cpu1 2 3 or whatever
depemding on the number of cores, plus double if hyperthreading is on)
Ondemand first checks scaling_available_governors and then sets
scaling_governor to ondemand. If you have this directory you should be
able to (as root) set this to performance instead. Or edit the file in
/etc/init.d/ to force performance instead of ondemand.
I am running 3.13.0-39-lowlatency here and will check some other machines
to see if this directory is missing there too.
--
Len Ovens
www.ovenwerks.net
3454
days inactive
3454
days old
linux-audio-user@lists.linuxaudio.org
8 comments
6 participants
participants (6)
-
Arve Barsnes -
Frank Neumann -
Harry van Haaren -
Len Ovens -
Ralf Mardorf -
Will Godfrey