Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: Force Sparc 5 Performance Tests
From: npr@jach.hawaii.edu (Nick Rees)
To: tech-talk@aps.anl.gov
Date: Thu, 17 Oct 1996 09:21:56 -1000 (HST)

Not really directly related to this, but I have sometimes found spy to be
misleading (particularly for periodic tasks driven off clock ticks),
and then I saw the following message on the VxWorks exploder. The
relevent paragraph is where it says:

> Spy reports snapshots of task CPU usage.  It's useful to see at large
> granularity which tasks are hogs.  One caveat: spy should be run with a
> non-integer multiple of the system clock (preferably a relative prime), and
> should collect at least 1500 samples or so per report.  The default parameters
> (5,100) are horrible.  spy(15,107) will work for most apps.

I think the moral is that if we are monitoring loads with spy, we
should be make sure we think about it, and use the same parameters for
both sides of a comparison.

I suspect it will make no real difference to the current comparison -
the factor of 6 sounds about right - but I am really posting it because
some people may not have seen this message before and may be
interested.

Cheers,

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: npr@jach.hawaii.edu


----- Begin Included Message -----

>From stan@rti.com  Fri Sep 27 16:01:35 1996
>From: Stan Schneider <stan@rti.com>
Date: Fri Sep 27 16:01:37 PDT 1996
Subject: Re: spy use

>> > A statistician could figure out how long to let it run at what
>> > spy clock rate to give whatever assurance you'd catch a task
>> > waking up every X microseconds and running for Y microseconds.
>> > With a long enough run, you *will* see hits on a task or ISR
>> > that runs for periods much less than the spy clock period.
>> 
>> I totally agree with John.  If you have periodic applications then
>> spy will give you good information if you let it run long enough.
>> I had a paper from a while ago where someone actually did the analysis
>> to show how long you had to run things to get whatever accuracy you
>> wanted on the task timing.
>> 

Hey!  I wrote that paper!  :-)  I'll post it to our web page next week &
announce when it's up.  It analyzes the statistics of sampling profilers.  The
accuracy available with even modest sampling is really pretty surprising.

The analysis applies to all statistical profilers, including spy and also our
dynamic execution profiler called "ScopeProfile".  Since there seems to be some
confusion in this thread, I'll take the liberty of pointing out some of the
differences between Spy, WindView, and ScopeProfile.  All these tools are
useful for tuning your application code for maximum performance.  They are very
different and mostly complementary.

Spy is a task-level profiler; it shows you how much CPU each task is using.
ScopeProfile is a *function-level* profiler; it analyzes how much CPU each
routine in your system is using (much finer resolution information than
reported by spy).  WindView shows when events occur, which tasks are running,
and when and why changes occur.  It's not really a profiler.

Spy reports snapshots of task CPU usage.  It's useful to see at large
granularity which tasks are hogs.  One caveat: spy should be run with a
non-integer multiple of the system clock (preferably a relative prime), and
should collect at least 1500 samples or so per report.  The default parameters
(5,100) are horrible.  spy(15,107) will work for most apps.

These tools give you different information.  They are most useful in different
situations.

For example, if your application is thrashing (spending most of its time
context switching), ScopeProfile (and spy) will simply report that most of the
CPU is being spent in the kernel.  WindView will show you which tasks are
switching, and display the events (e.g.  interrupts) that are causing the
switches.  It will show how long it took to respond to the interrupts, what was
delayed, etc.  Windview is clearly the tool to use in this situation.

On the other hand, if you have one task hogging the CPU, WindView (and spy)
will only tell you that one task is running most of the time.  ScopeProfile
will provide a detailed function-by-function analysis, breaking down the
individual routines within the task that are burning the CPU.  It will give you
a map of what that task is doing, what routines are being called, what
routines they call, and point out the inefficiencies.  You could sprinkle user
events around your code with WindView, but that's not really practical.  This
is the domain of a profiler.

So, all three tools help you tune the performance of your code.  However, they
provide different perspectives: WindView offers precise measurements of event
timing, ScopeProfile provides a detailed functional analysis of where your CPU
time is being used.  Spy simply tells you which tasks are active.


HTH,

        -- Stan


=============================================================================
=                                           =                               =
=   Stan Schneider                          =   email: stan@rti.com         =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312 x104  =
=   155A Moffett Park Drive, Suite 111      =   Fax:   (408) 734-5009       =
=   Sunnyvale, CA 94089                     =   http://www.rti.com          =
=                                           =                               =
=============================================================================




----- End Included Message -----



Navigate by Date:
Prev: Performance 25 Mhz 68040 (MV167) Marty Kraimer
Next: Re: GDCT under EPICS R3.13 Ric Claus
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: Force Sparc 5 Performance Tests Peregrine McGehee
Next: Performance 25 Mhz 68040 (MV167) Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·