Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

spy use

134 views

Skip to first unread message

Fred Roeber

unread,

Sep 26, 1996, 3:00:00 AM9/26/96

john finley wrote:

> Spy's one of those neat tools that's simple, yet still does
> a very good job. But you really need to know what it's doing
> to use it correctly.
>
> 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.

One thing to note about measuring interrupt timings with spy, is that
you will only get the timing for interrupt handlers and code that
don't mask the aux clock interrupt that is used to generate the data
needed for the spy report. I have run spy off of a non maskable
interrupt before to get accurate timings including all interrupt
levels and code that locked out interrupts but that was back when I
had source access and could tweak the spy code a little to get it
to work in this mode.

> I can only guess on how a windview works. And that guess is
> that it hooks the task switch, and reads a clock with very
> good resolution (usec). Does windview count interrupt time?
> If so, then it has to hook ISR entry and return, I think.

WindView works entirely differently from spy (which is a profiler).
With WindView, the object code for vxWorks has extra code added to
many key points in the operating system to create a record of the
execution of that code in a large circular buffer. Each of these
event records is time stamped using a local high resolution clock.
This mode of operation means that WindView is much more useful to
look at the explicit timing of sequences of code including code that
doesn't run periodically. The WindView manual has a complete
description of all the points in the operating system that are
instrumented (plus you can add your own instrumentation points).
We actually sell a product called TraceMaker that makes WindView
work even better. Fred

Stan Schneider

unread,

Sep 27, 1996, 3:00:00 AM9/27/96

>> > 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: st...@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 =
= = =
=============================================================================

0 new messages