On Wed, 2010-04-07 at 02:02 +0200, tim vets wrote:
>
>
> 2010/4/6 Tim Blechmann <t...@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.
Roman
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
