Rob Jenkins (robj++at++reading.sgi.com)
Tue, 9 Nov 1999 09:58:32 -0000
Given that you say this happens with no database loaded and the symptoms
change with OS, I would suggest taking a look at what IRIX is up to when the
problem happens. You mention that "The system is optimized regarding the
number of running demons, slice_size and NOINTR parameters. " which is
always a good thing although in my experience it can be a) hard to predict
what the best optimizations are and b) hard to anticipate side effects of
the optimizations. So, the bottom line is always that applying OS/system
tuning is a good thing but, check the behavior as you make changes, and make
changes in small stages.
If you can roughly predict how often the glitch happens then try using par
to catch what's happening:
setenv PFNFYLEVEL 9
perfly &
note the process ids and CPU assignments
run par -rQQt N
where N is a number of seconds sufficient to catch a glitch, or run without
the t option and just stop the run ass soon as you see a glitch.
On a 10 CPU system you'll get huge output so use grep to filter it down
and/or pipe to a file to then search later.
What you're looking for is where a performer process got preempted early by
IRIX so look for process with a high % of 'preempted short' in the summary,
also in the trace look for places where it the regular pattern get
disrupted.
The par output can be a little overwhelming, sometimes a clue just leap out
though, if not consider. My guess is that some non-pf process is running
when you don't expect it too, if it's not that then you should at least rule
that out before trying other stuff.
Cheers
Rob
-----Original Message-----
From: Haubner, Michael [mailto:Michael.Haubner++at++kmweg.de]
Sent: 09 November 1999 08:52
To: 'info-performer++at++sgi.com'
Subject: onyx1 perfly problem
Hi,
please help us finding the reason for some strange timing effects occuring
in performer applications running on an Onyx1 IR 3pipe 10 cpu system (Irix
6.2,
recommended patches). We are running an unmodified perfly with any data-
base loaded, with root permissions, cpu locking and different multipipe
modes
with and without genlocking. The system is optimized regarding the number
of running demons, slice_size and NOINTR parameters.
There are 2 small screen shots attached showing the problem:
sometimes the last segment of the application time in the statistics (low
thin
line) gets very long for some frames and then returns to its normal length.
It
seems that the application somehow locks to the end of the drawing process.
When changing the level of detail settings the mentioned segment of the
application time changes according to the drawing time.
Another interesting thing is the starting point of the drawing stage:
normally it
should start a small amount of time after the frame boundary. But during the
strange behaviour the drawing process begins its work exactly at the
beginning of the new frame.
BTW: - We have also tested another Onyx1 with 2 IR pipes with the same
results.
- On Irix 6.5.5 and Performer 2.2.6 the problem still exists but
occurs less frequent.
- The screen shots are made using perfly without any database
loaded.
Thank you in advance,
Michael Haubner
<<perfly.normal.gif>> <<perfly.problem.gif>>
This archive was generated by hypermail 2.0b2 on Tue Nov 09 1999 - 01:59:22 PST