On Wed, 2010-04-07 at 02:02 +0200, tim vets wrote:
2010/4/6 Tim Blechmann tim@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