Brian Furtaw (brian++at++dingbat.clubfed.sgi.com)
Sat, 4 Apr 1998 07:15:10 -0500
If your running IRIX 6.2 or greater get yourself a copy of Windview run the
apps in single process mode `perfly -m 0' with the runon, command don't pick
CPU 0. Then start `rtmon-client' specifing the CPUs you asked for in the runon
command. i.e. % rtmon-client -o -p <CPUa>,<CPUb> -f pause.test
Let the applications run until a freeze happens then control c or kill the
rtmon-client program. Start up Windview use File->Analyze All to read in the
pause.test* files. Then choose View->New Graph to see what windview found. You
will see a one to three second gap in processing where your apps froze on the
Windview timeline. You can then see what else was running on that CPU while
your app was frozen by scanning up and down the graph.
I used this same technique to debug a customer problem last year and found that
sar was dumping its data to disk during the freezes. Once sar was turned off
the problem went away. They where using sar to collect a lot of detailed
statistics which required long write backs to disk from memory cache.
If you have any questions don't hesitate to ask,
Brian
On Apr 3, 1:26pm, Rob Jenkins wrote:
> Subject: Re: Frame Freeze
> We're running 2 separate 'perfly' executables on an 8 processor ONYX.
> > We've bound each perfly to it's own processor using the runon command on
> > the command line. We also have several other processes running on all
> > of the other processors. The display freezes for 1-3 seconds quite
> > frequently. We've tried taking out the runon command and letting the
> > perfly run freely on whatever processor it chooses. This does not stop
> > the freezing display. We've cut the frame rate down to 20.0 HZ and that
> > helped the frequent freezes, but it makes the display more jumpy. Does
> > anyone have any suggestions on how to avoid the freezing display?
> >
> > Should we try to bind the Draw processes to their own processors, and
> > put the APP and CULL somewhere else?
> >
> > Thanks in advance for any help.
> >
> > Suzie
> >
> > --Press any key to go on.--
> >
>
> Suzie
>
> Sounds like something is fighting for CPU time. I would suggest setting
> PFNFYLEVEL 6, look at the Performer Process State messages to see what pids
run
> on what CPUs then use par -rQQtN where N is enough seconds to catch a freeze
(
> you'll need to run that as root ). This should show you what processes run on
> which CPUs with what priority and also what is switching them on/off CPUs.
The
> if you see obvious conflicts you can try moving things around. Make sure you
> have the latest recommended patchset too to get the latest kernel roll up
patch
> ( see www.sgi.com/support for patchsets ).
>
> Cheers
> Rob
>
> --
> ________________________________________________________________
> Rob Jenkins mailto:robj++at++sgi.com
> Silicon Graphics, Mtn View, California, USA
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
>-- End of excerpt from Rob Jenkins
--
----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
Brian Furtaw (brian++at++sgi.com)
VisSim Technical Consultant
12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293
Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:12 PDT