[PD] urgent - cpu going to 100% / top weirdness

Jaime Oliver jaime.oliver2 at gmail.com
Mon Feb 9 00:11:27 CET 2009


Hi,
are this cpu hikes actually affecting sound or image?

I'm no expert but I have some ideas.

When things like this have happened to me it has been because i am running
out of ram. Like when you play a video and for some reason I see my cpu
affected. I think the reason is that I start using swap memory and/or
because swap memory is insufficient. When this has happened loading images
or other files and running out of ram i find ways of reducing the size of
the images, etc.

I run all visual stuff in separate a pd instance with -nosound flag. Unless
you are not using Pd/GEM for the visual part... Do you have a graphics card?
maybe try reducing the frame rate of graphics computation. I suppose you can
go down to 24fps rendering without noticeable problems.


The way I look for loops or other forms of ineffectiveness is to put a 0
switch in all audio patches and check that cpu is very low in those
circumstances. Otherwise there is usually a problem unless you are doing
really intense control computation.

Also, since you have a dual processor there is a command to see both
processors at the same time which isn't top. it is something like cat
/proc/cpu or similar, my linux machine is away right now so I can't test it.

anyway,

hope this helps!'

J

On Sun, Feb 8, 2009 at 11:31 AM, Damian Stewart <damian.ml at frey.co.nz>wrote:

> hey,
>
> i'm setting up for an exhibition in Madrid that opens on Tuesday (it's
> called VIDA and it's at Matadero Madrid, come down if you're in town.)
>
> so, i'm trying to track down a strange issue with Pd jumping to 100% cpu
> periodically, once every 15 seconds, when i run another cpu-intensive task.
> i'm running Pd 0.40-2, installed via apt-get on Ubuntu 8.04. (i have the
> same issue with the Pd-extended 0.40-3 .deb from the puredata.info
> website). this is on a dual-core Pentium-D 3GHz cpu. i'm using ALSA with an
> MAudio Delta 66 card. (linux is *so* not ready for multichannel audio
> unless you've got a high end RME device, but that's another story).
>
> if i start up top, and just run pd, it chugs along fine. the cpu usage line
> at the top edge of the screen in top stays around 20%us, with around 80%
> idle time. and the entry for Pd gives a CPU usage of 63% (i don't
> understand what these two values mean or why they differ)
>
> if i then start up a cpu-intensive graphical task that sits around 100% but
> is only single-threaded, the weirdness begins. in top, the total CPU usage
> line jumps up to 70%. in the listing of processes below, the cpu-hungry
> graphical task sits on around 97%, but the Pd process is now down to 36%.
> after running for around 30 seconds, the Pd process jumps up to 100%,
> totally killing the framerate on the cpu-hungry graphical task. it stays
> like this for 10 or so seconds, then drops back down to 36%, before
> repeating the cycle again after another 20-30 seconds.
>
> i tried running pd with -nogui and -rt -- no change. i also tried running
> pd with niceness -10 and the graphical task with niceness 10 -- again, no
> change.
>
> so, questions. first, wtf? why is top reporting a lower cpu usage in the
> second scenario than in the first?
>
> second: how can i stop this?
>
> third: it's possible this is being caused by an almost-infinite loop in one
> of my patches. how can i profile them to test this?
>
> thanks
> d
>
> --
> damian stewart | skype: damiansnz | damian at frey.co.nz
> frey | live art with machines | http://www.frey.co.nz
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Jaime E Oliver LR

joliverl at ucsd.edu
www.realidadvisual.org/jaimeoliver
www-crca.ucsd.edu/
www.realidadvisual.org

858 202 1522
9168 Regents Rd. Apt. G
La Jolla, CA 92037
USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090208/30745211/attachment.htm>


More information about the Pd-list mailing list