[PD] pd and multi-core processors

Roman Haefeli reduzierer at yahoo.de
Wed Apr 7 10:21:42 CEST 2010

On Wed, 2010-04-07 at 02:02 +0200, tim vets wrote:
> 2010/4/6 Tim Blechmann <tim at klingt.org>
>         > With my patch open i get these values (average):
>         > cpu1 60% cpu2 60% cpu3 11% cpu4 2%
>         > Then, when I open a pd~ patch:
>         > cpu1 80% cpu2 80% cpu3 40% cpu4 3%
>         the average cpu load won't tell you a lot, since the cpu speed
>         is usually
>         not constant, but may be modulated (adding some latency
>         hotspots). in
>         general, i'd recommend to disable frequency scaling, turbo
>         mode (for nehalem
>         cpus) and smt, since it may confuse numbers and can increase
>         the thread
>         wakeup latency significantly, if you want to use a machine for
>         low-latency
>         real-time audio applications.
> thanks for the tip. I have no idea how to do that though.
> I admit not having searched for very long (it's late), but i couldn't
> find an easy peasy how-to disable frequency scaling,

on ubuntu usually:
$ sudo cpufreq-selector -g performance

I guess this is the same as overriding the sysctl files in:
/sys/devices/system/cpu/cpuX/cpufreq on modern linuxes.

I don't know about the default kernel, but in the realtime kernel
running applications with realtime privileges (for instance pd -rt) and
dynamic cpu frequency scaling doesn't work well together, so I guess one
is better off by disabling it. I tend to believe that cpu frequency
scaling fails to adapt when 'pd -rt' requires it, because Pd has such a
high priority, even higher than the governor controlling the scaling.
When using other (low priority) applications, gcc for instance, scaling
works as expected.


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list