Real-time priority

[Micheal Allen Thompson]

hmmm

I run pd on my SGI under root for performance with the nice negative
values to increase its priority level, but only for performance
reasons... I had a 4 SGI installation pd/GEM running for 3 days without
a crash of IRIX or pd/gem. CPU usage ranged from %50 to %98 in some
cases. This could not run under normal usage... I also was using the SGI 
soft synth so that I could do 8 channel audio from my O2(and 3D graphics 
and audio processing).... (when can we see 8 channel audio on SGI?) 


Now I have been messing around with jMax/fts and it runs well... would pd
run as well under real-time system tunings? 

i like pd better than jMax... but fts does do audio real well. 

michael


On Tue, 6
Apr 1999,
Guenter Geiger wrote:

> Hi Larry !
> 
> Actually , when writing about solving the realtime scheduling problem,
> I was thinking about your proposal, which, I think you posted over
> a year ago on the list.
> 
> With this solution it would be possible to reliably run pd under root.
> We could check the performance of the system and switch to normal
> scheduling, when we realize that pd uses more than, say 95% of the CPU.
> 
> I found out, that with some Computer - Soundcard combinations, pd runs
> very well under root, but "clicks" when run as normal user.
> 
> A reliable solution for high priority scheduling  should give us better
> performance,
> at least under Linux and SGI, so we should try to find a common solution for
> them.
> 
> Guenter
> 
> 
> > -----Original Message-----
> > From: root at westnet.com [mailto:root at westnet.com]On Behalf Of Larry
> > Troxler
> > Sent: Thursday, April 01, 1999 5:42 PM
> > To: pd-list
> > Subject: Real-time priority
> >
> >
> > Hi, I haven't been using PD lately, but thought but the
> > recent messages
> > about running PD as root insterested me.
> >
> > I assume that PD grabs the Posix real-time scheduling algorhihm when
> > running as root.
> > Once, when playing around with the some other real-time audio code, I
> > was able to use a second thread as a sort of software watchdog.
> > The watchdog thread would run periodically, checking and clearing a
> > global flag that the audio thread would write everytime it
> > completed its
> > output generation loop. The watchdog thread ran one priority level
> > higher than the audio thread.
> >
> > This was a while ago, but I remember that the concept seemed
> > to work. Am
> > I missing something with this idea?
> >
> > Larry
> >
> > --  Larry Troxler --  lt at westnet.com  --  Patterson, NY USA  --
> >
> 

Michael A. Thompson 
Unix SysAdmin.  
[IRIX - NeXTStep - Linux] 
University of North Texas 
Center for Experimental Music and Intermedia
[C.E.M.I.]
Office: (940) 565-2382

* Windows 95: n.  32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand 1 bit of
competition.