Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor?
..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net .....................................................
On Mon, Apr 05, 2010 at 11:59:37AM +0200, vedran wrote:
can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor?
If you use the new [pd~] object, the stuff you do inside of this may run on the second core. Without this, Pd will only use one, IIR.
Ciao
Frank
hey vedran,
pd~ is a way of opening another instance of pd from within a patch.
ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will use one processor.
nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed.
for sound, you can create objects in faust and make multithreaded audio externals.
other than that, the processes in a patch are single threaded.
J
On Mon, Apr 5, 2010 at 2:59 AM, vedran vedran.kolac@gmail.com wrote:
Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor?
..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net .....................................................
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
has anyone been using pd~ successfully ? I am trying it out, but i get very poor results. It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it? Is there a way to check this? thanks!
2010/4/5 Jaime Oliver jaime.oliver2@gmail.com
hey vedran,
pd~ is a way of opening another instance of pd from within a patch.
ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will use one processor.
nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed.
for sound, you can create objects in faust and make multithreaded audio externals.
other than that, the processes in a patch are single threaded.
J
On Mon, Apr 5, 2010 at 2:59 AM, vedran vedran.kolac@gmail.com wrote:
Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor?
..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net .....................................................
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
tim vets a écrit :
has anyone been using pd~ successfully ?
yes
I am trying it out, but i get very poor results. It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it?
if your OS can deal with multiple CPU, then it should run the pd and pd~ process on 2 different core.
Is there a way to check this?
depend on your OS.
cyrille
thanks!
2010/4/5 Jaime Oliver <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com>
hey vedran, pd~ is a way of opening another instance of pd from within a patch. ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will use one processor. nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed. for sound, you can create objects in faust and make multithreaded audio externals. other than that, the processes in a patch are single threaded. J On Mon, Apr 5, 2010 at 2:59 AM, vedran <vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>> wrote: Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor? ..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Jaime E Oliver LR www.jaimeoliver.pe <http://www.jaimeoliver.pe> 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
tim vets a écrit :
has anyone been using pd~ successfully ?
yes
I am trying it out, but i get very poor results.
It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it?
if your OS can deal with multiple CPU, then it should run the pd and pd~ process on 2 different core.
Ok, I have no idea id ubuntu-studio Hardy supports it...
Is there a way to check this?
depend on your OS.
ubuntu
gr, Tim
cyrille
thanks!
2010/4/5 Jaime Oliver <jaime.oliver2@gmail.com mailto: jaime.oliver2@gmail.com>
hey vedran, pd~ is a way of opening another instance of pd from within a patch.
ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will use one processor.
nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed.
for sound, you can create objects in faust and make multithreaded audio externals.
other than that, the processes in a patch are single threaded.
J
On Mon, Apr 5, 2010 at 2:59 AM, vedran <vedran.kolac@gmail.com mailto:vedran.kolac@gmail.com> wrote:
Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor? ..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- Jaime E Oliver LR
www.jaimeoliver.pe http://www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA
Pd-list@iem.at mailto:Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
tim vets a écrit :
tim vets a écrit : has anyone been using pd~ successfully ? yes I am trying it out, but i get very poor results. It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it? if your OS can deal with multiple CPU, then it should run the pd and pd~ process on 2 different core.Ok, I have no idea id ubuntu-studio Hardy supports it...
yes, linux does suport multiple processor system / administration / system monitor you should see both processor used.
c
Is there a way to check this? depend on your OS.ubuntu
gr, Tim
cyrille thanks! 2010/4/5 Jaime Oliver <jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com> <mailto:jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com>>> hey vedran, pd~ is a way of opening another instance of pd from within a patch. ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will use one processor. nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed. for sound, you can create objects in faust and make multithreaded audio externals. other than that, the processes in a patch are single threaded. J On Mon, Apr 5, 2010 at 2:59 AM, vedran <vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>>> wrote: Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor? ..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>> ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Jaime E Oliver LR www.jaimeoliver.pe <http://www.jaimeoliver.pe> <http://www.jaimeoliver.pe> 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ------------------------------------------------------------------------ _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2010/4/5 cyrille henry ch@chnry.net
tim vets a écrit :
tim vets a écrit :
has anyone been using pd~ successfully ?yes
I am trying it out, but i get very poor results. It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it?if your OS can deal with multiple CPU, then it should run the pd and pd~ process on 2 different core.
Ok, I have no idea id ubuntu-studio Hardy supports it...
yes, linux does suport multiple processor system / administration / system monitor you should see both processor used.
hi Cyrille,
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% so, still plenty of overhead on the 4th core, but it doesn't seem to be used. soundwise, I get fast and regular clackles. ...sounds like a squarewave based amplitude modulator... The ubuntu I use is an image of an old installation that was originally installed on a single core machine. Does that matter ? gr, Tim
c
Is there a way to check this?depend on your OS.
ubuntu
gr, Tim
cyrille
thanks! 2010/4/5 Jaime Oliver <jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com> <mailto:jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com>>> hey vedran, pd~ is a way of opening another instance of pd from within a patch. ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will useone processor.
nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed. for sound, you can create objects in faust and makemultithreaded audio externals.
other than that, the processes in a patch are single threaded. J On Mon, Apr 5, 2010 at 2:59 AM, vedran <vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>>> wrote: Hi! can someone tell me if one instance of pd (with gem) can use more than one core on multi-core processor? ..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>> ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Jaime E Oliver LR www.jaimeoliver.pe <http://www.jaimeoliver.pe> <http://www.jaimeoliver.pe> 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2010/4/6 tim vets timvets@gmail.com
2010/4/5 cyrille henry ch@chnry.net
tim vets a écrit :
tim vets a écrit :
has anyone been using pd~ successfully ?yes
I am trying it out, but i get very poor results. It seems like a patch loaded with pd~ is a lot heavier than the same loaded as a regular abstraction (DIO errors, see also my message "pd~ and DIO errors"). I assumed it would run on another processor core...but does it?if your OS can deal with multiple CPU, then it should run the pd and pd~ process on 2 different core.
Ok, I have no idea id ubuntu-studio Hardy supports it...
yes, linux does suport multiple processor system / administration / system monitor you should see both processor used.
hi Cyrille,
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% so, still plenty of overhead on the 4th core, but it doesn't seem to be used. soundwise, I get fast and regular clackles. ...sounds like a squarewave based amplitude modulator... The ubuntu I use is an image of an old installation that was originally installed on a single core machine. Does that matter ?
I guess it doesn't, the output of dmesg | grep CPU# is: Initializing CPU#0 Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 checking TSC synchronisation [CPU#0 > CPU#1]: passed checking TSC synchronisation [CPU#0 > CPU#2]: passed checking TSC synchronisation [CPU#0 > CPU#3]: passed gr, Tim
gr,
Tim
c
Is there a way to check this?depend on your OS.
ubuntu
gr, Tim
cyrille
thanks! 2010/4/5 Jaime Oliver <jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com> <mailto:jaime.oliver2@gmail.com <mailto:jaime.oliver2@gmail.com>>> hey vedran, pd~ is a way of opening another instance of pd from within a patch. ideally you want gem and sound on separate instances (connected via udp, pd~ or some other way). each of these processes will useone processor.
nicely enough, pd's graphical interface and the actual process, are separate threads, so you (or more precisely your OS) might have them in separate processors if needed. for sound, you can create objects in faust and makemultithreaded audio externals.
other than that, the processes in a patch are single threaded. J On Mon, Apr 5, 2010 at 2:59 AM, vedran <vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>>> wrote: Hi! can someone tell me if one instance of pd (with gem) canuse more than one core on multi-core processor?
..................................................... vedran kolac ..................................................... gTalk - vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com> <mailto:vedran.kolac@gmail.com <mailto:vedran.kolac@gmail.com>> ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Jaime E Oliver LR www.jaimeoliver.pe <http://www.jaimeoliver.pe> <http://www.jaimeoliver.pe> 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
tim
sorry if i missed the announcement, but where can i find this [pd~] object and some documentation? cheers
On Tue, Apr 6, 2010 at 9:36 PM, Tim Blechmann tim@klingt.org wrote:
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.
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
tim
-- tim@klingt.org http://tim.klingt.org
Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2010/4/6 Jon potaxpotax@gmail.com
sorry if i missed the announcement, but where can i find this [pd~] object and some documentation? cheers
Hi Jon, i think it comes with the latest pd extended, at least i didn't explicitly install it and i do have it, so... gr, Tim
On Tue, Apr 6, 2010 at 9:36 PM, Tim Blechmann tim@klingt.org wrote:
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.
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core
cpu.
tim
-- tim@klingt.org http://tim.klingt.org
Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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, or about that turbo mode and smt stuff... maybe you (or someone else) can explain this in a bit more detail?
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
hmm, if I try to load one patch into a pd~ object I get garbled sound, even without switch~ing it on. Would you think if I split off more of my main patch into more pd~ objects it would improve ? The fact that using pd~ results in more hickups than a normal abstraction leads me to suspect something else is wrong...
goodnight, Tim
tim
-- tim@klingt.org http://tim.klingt.org
Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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, or about that turbo mode and smt stuff... maybe you (or someone else) can explain this in a bit more detail?
usually these are bios options. the basic idea for disabling this stuff is to avoid system-level interrupts, that could introduce considerable wakeup latencies in the worst case.
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
hmm, if I try to load one patch into a pd~ object I get garbled sound, even without switch~ing it on. Would you think if I split off more of my main patch into more pd~ objects it would improve ? The fact that using pd~ results in more hickups than a normal abstraction leads me to suspect something else is wrong...
if your patch works fine on a single cpu, but not with pd~, i would also suspect, that something else is going wrong. there could be various reasons for the hickups like scheduling issues, buffer synchronization issues and the like. however, i have no insight in the implementation of pd~, but since pd~ is part of vanilla pd, i am sure, miller will be interested in resolving all issues, that pd~ may have.
cheers, tim
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
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.
cpu scaling may occur at the level of the operating system and at hardware level (controlled by the bios). e.g. some systems will modulate the clock to keep the cpu temperature in a certain range, although you are in performance mode. this is invisible at the scope of the os, although it will increase the worst-case scheduling latency.
-
cyrille henry -
Frank Barknecht -
IOhannes m zmoelnig -
Jaime Oliver -
Jon -
Roman Haefeli -
Tim Blechmann -
tim vets -
vedran