Experimental Physics and
Industrial Control System

[email protected] (Nick Rees) · 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: [email protected]

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

>From [email protected]  Fri Sep 27 16:01:35 1996
>From: Stan Schneider <[email protected]>
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: [email protected]         =
=   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 -----

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System