hi all
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
could it be, that when pd is running in realtime mode, its priority is higher then the one of the process, that controls the cpu frequency, so that cpu time is assigned rather to pd and only at times, when pd is not using it, the governor can adjust the frequency (which would be the loweset, since pd is not using much cpu at that time)?
i wonder, what other people do in a performative situation? do you simply turn automatic scaling off and set frequency to the highest value? or is it only me having this issue?
while we are at priorities: i figured out, that all four combinatios are possible: pd -rt, jackd -R pd -nrt, jackd -R pd -rt, jackd pd -nrt, jackd
i guess, that the first one should be used for best performance, right? but how to set priorities between jackd and pd? can this be fine-tuned at all (i know you can fine-tune jackd) ? if so, which should have higher priority?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli a écrit :
hi all
...
i wonder, what other people do in a performative situation? do you simply turn automatic scaling off and set frequency to the highest value? or is it only me having this issue?
the only thing i'm doing is stopping the frequency scalling demon :
sudo /etc/init.d/powernowd stop
cyrille
you might have guessed it, but for the sake of correctness:
this is:
- linux / ubuntu hardy
- intel core 2 duo (800 -> 2401 MHz)
- pd vanilla 0.42 test5
On Sun, 2008-12-07 at 16:58 +0100, Roman Haefeli wrote:
hi all
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
could it be, that when pd is running in realtime mode, its priority is higher then the one of the process, that controls the cpu frequency, so that cpu time is assigned rather to pd and only at times, when pd is not using it, the governor can adjust the frequency (which would be the loweset, since pd is not using much cpu at that time)?
i wonder, what other people do in a performative situation? do you simply turn automatic scaling off and set frequency to the highest value? or is it only me having this issue?
while we are at priorities: i figured out, that all four combinatios are possible: pd -rt, jackd -R pd -nrt, jackd -R pd -rt, jackd pd -nrt, jackd
i guess, that the first one should be used for best performance, right? but how to set priorities between jackd and pd? can this be fine-tuned at all (i know you can fine-tune jackd) ? if so, which should have higher priority?
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
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Wow, this clears up an old mystery for me - thanks for starting this thread!
Another way to grab CPU power is to run "pd -nosleep" which causes it to spin instead of sleeping when it goes idle. On my system at least, I see the CPU immediately go to full speed. (But only do this on a system with more than one CPU. And I'm not sure how this will play with jack - I'm using Alsa directly.)
cheers Miller
On Sun, Dec 07, 2008 at 05:17:38PM +0100, Roman Haefeli wrote:
you might have guessed it, but for the sake of correctness:
this is:
- linux / ubuntu hardy
- intel core 2 duo (800 -> 2401 MHz)
- pd vanilla 0.42 test5
On Sun, 2008-12-07 at 16:58 +0100, Roman Haefeli wrote:
hi all
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
could it be, that when pd is running in realtime mode, its priority is higher then the one of the process, that controls the cpu frequency, so that cpu time is assigned rather to pd and only at times, when pd is not using it, the governor can adjust the frequency (which would be the loweset, since pd is not using much cpu at that time)?
i wonder, what other people do in a performative situation? do you simply turn automatic scaling off and set frequency to the highest value? or is it only me having this issue?
while we are at priorities: i figured out, that all four combinatios are possible: pd -rt, jackd -R pd -nrt, jackd -R pd -rt, jackd pd -nrt, jackd
i guess, that the first one should be used for best performance, right? but how to set priorities between jackd and pd? can this be fine-tuned at all (i know you can fine-tune jackd) ? if so, which should have higher priority?
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
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Roman Haefeli a écrit :
you might have guessed it, but for the sake of correctness:
this is:
- linux / ubuntu hardy
- intel core 2 duo (800 -> 2401 MHz)
- pd vanilla 0.42 test5
you're using pd test version for your performance?
i've got problem loading my old patch with this version. is it really stable?
cyrille
On Sun, 2008-12-07 at 16:58 +0100, Roman Haefeli wrote:
hi all
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
could it be, that when pd is running in realtime mode, its priority is higher then the one of the process, that controls the cpu frequency, so that cpu time is assigned rather to pd and only at times, when pd is not using it, the governor can adjust the frequency (which would be the loweset, since pd is not using much cpu at that time)?
i wonder, what other people do in a performative situation? do you simply turn automatic scaling off and set frequency to the highest value? or is it only me having this issue?
while we are at priorities: i figured out, that all four combinatios are possible: pd -rt, jackd -R pd -nrt, jackd -R pd -rt, jackd pd -nrt, jackd
i guess, that the first one should be used for best performance, right? but how to set priorities between jackd and pd? can this be fine-tuned at all (i know you can fine-tune jackd) ? if so, which should have higher priority?
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
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2008-12-07 at 20:27 +0100, cyrille henry wrote:
Roman Haefeli a écrit :
you might have guessed it, but for the sake of correctness:
this is:
- linux / ubuntu hardy
- intel core 2 duo (800 -> 2401 MHz)
- pd vanilla 0.42 test5
you're using pd test version for your performance?
i've got problem loading my old patch with this version. is it really stable?
i haven't encountered any issues regarding stability, though i haven't been in a situation yet, where the stability of pd was a matter of life and death.
the most 'intriguing' change is probably the possibility for externals to override internals with the same name. namely did i have issues with [pack] and [unpack] from zexy, because of that and because they were buggy (fixed now). personally, i am still very sceptic about this so-called feature. but this would belong to another thread.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
I don't remember being hit by this, but my memory may trick me. I'd use cpufreq-set(1) as root to switch the scaling governor to "performance" when performing.
Ciao
Frank
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
I don't remember being hit by this, but my memory may trick me. I'd use cpufreq-set(1) as root to switch the scaling governor to "performance" when performing.
i usually set the cpu speed to the lowest feasible frequency ... the slower the cpu, the cooler the computer, so less audible noise is produced by the cpu fan during the performance ... using gnome's cpufreq-applet, one can change the scaling governor/ frequency with two mouse clicks ...
t
On Sun, 2008-12-07 at 19:43 +0000, Tim Blechmann wrote:
i encountered, that 'ondemand' cpu scaling doesn't work correctly when running pd with realtime priority. even if pd is using 80% or more resources (of one core), the cpu frequency is not raised and staying at 800MHz. i can force it to go up by running an instance of 'burnMMX' (or something else, that burns as many cycles as possible). when running pd with '-nrt', automatic scaling works fine. also, as a workaround, i can set the scaling_governor to 'userspace' and then set the cpu frequency manually.
I don't remember being hit by this, but my memory may trick me. I'd use cpufreq-set(1) as root to switch the scaling governor to "performance" when performing.
i usually set the cpu speed to the lowest feasible frequency ... the slower the cpu, the cooler the computer, so less audible noise is produced by the cpu fan during the performance ... using gnome's cpufreq-applet, one can change the scaling governor/ frequency with two mouse clicks ...
so speaks the minimalist, cpu-wise..... ;-)
unfortunately, many netpd-synths and netpd-fx aren't that modest, cpu-wise.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
i usually set the cpu speed to the lowest feasible frequency ... the slower the cpu, the cooler the computer, so less audible noise is produced by the cpu fan during the performance ... using gnome's cpufreq-applet, one can change the scaling governor/ frequency with two mouse clicks ...
so speaks the minimalist, cpu-wise..... ;-)
unfortunately, many netpd-synths and netpd-fx aren't that modest, cpu-wise.
well, using a more efficient signal processing engine, you can reduce the cpu load considerably :)
cheers, tim
-
cyrille henry -
Frank Barknecht -
Miller Puckette -
Roman Haefeli -
Tim Blechmann