Sorry for the late comment on this thread (been away for a few days...)

At 09:01 PM 1/24/97 -0800, Stan Sieler wrote:
>      then, to see what CPU utilization is right.....now, do:
>
>
>          get process CPU time for the background process.
>          pause 10 seconds
>          get process CPU time for the background process.

I saw this approach used by an SE (Gerry ?) from Englewood CO in a tool
called RESPONSE done in the late 70's.  Essentially this technique is a way
to indirectly measure how long a process waits on the dispatch queue after
becoming ready to execute.  It is possible to get into some very technical
discussions on all of this, but essentially I've supported/promoted this
technique over the other, generally used approach of measuring the time
period between terminal reads (which does not consider the differences in
application processing/different code execution paths between the
satisfaction of a terminal read and the next posting of the next terminal
read).

As it turns out, if you utilize the PAUSE intrinsic, the intrinsic basically
pauses for the lessor of 5 seconds, or the remaining portion of the
requested interval.  If it didn't pause in small intervals one could not
break-abort a process on a time delay.  This was because when a process was
on the TRL (Timer Request List) there was no way to notify the dispatcher of
the break when the dispatcher was deciding which process to give the CPU
next.  And it wasn't efficient to have the dispatcher check the process
table information each dispatch cycle... :)

Basically, when using the PAUSE intrinsic and this 5-second cycling occurs,
your process will consume a small amount of CPU time for each 5-second
interval even though it doesn't return to your measurement loop.  So if you
chose to vary the delay amount in order to fit as many of these within a
minute as possible, be careful as the measurement could be inconsistent
depending upon the number of measurements that actually might occur within
the period and the fact that this will vary depending upon the system load.
The potential inconsistency may influencing your measurement.

Also, when the time period was completed, if the process was in a circular
queue the PAUSE intrinsic placed the process in the top of the queue upon
return.  Knowing this I sometimes called PAUSE for a very small amount of
time in some large processing applications as opposed to using PM to
change/upgrade the processes execution priority periodically during
execution.... :-)  But if you are actually wanting to understand the system
reponse to processes as they are influenced by the circular queue rules,
this will not necessary give you a clear picture because of its resetting of
the current process's place in the queue.

Anyway, I always found it more meaningful to use the undocumented DELAY
procedure instead.  The results tended to be more accurate and not clouded
with the influences of the other aspects of the PAUSE intrinsic. In this
case the process stayed on the TRL for the entire duration with out the
5-second windowing processing done by PAUSE.  It also doesn't change your
position in the process queue, keeping your process priority the same and
more closely emulating that of the other processes in circular queues if
that is where you choose to use the product. However, DELAY is not break-able!

Its argument is a 32-bit integer specifying the number of milliseconds to
wait.  It used to be that this value should be basically rounded to the
nearest 300 Ms because of how the dispatcher operated, but I don't know
today if this makes any difference.

I've seen this procedure used incorrectly.  A programmer inadvertantly
called it with a negative 32-bit value because of an error in the interval
calculation which didn't consider a rollover of the counter.  Basically the
request was for the process to 'sleep' for something a little over 48 days.
Needless to say it was re-boot time as there is no way to interrupt a call
the DELAY (at least at that time!).  So one must be careful, as the passed
value is treated as an unsigned integer... :-)

Taking into account the wall time, one can program a loop such that this
measurement is taken several times within a minute and then averaged.  When
done over a period of time, at a minute-level of granularity, one gets a
fairly good measurement of 'system' response time, regardless of the
application mix. It also gives you a trend, which is what one wants to
monitor anyway...

Whether you use the DELAY procedure or the PAUSE intrinsic depends upon your
needs.  When I was dealing with this in a process manufacturing situation
with real-time events, I needed to eliminate the influences on the
measurement so as to be consistent as possible through the sampling periods.
Perhaps these aspects of PAUSE no longer exist, as its probably been 10
years since I did much work in this area of performance measurement and the
affect of timer requests, dispatcher processing, cycling aspects of the
PAUSE intrinsic, etc., may be quite different in terms of their
relationships and some aspects of this may no longer apply....

Bottom line is I agree with Stan in terms of this technique and type of
measurement of 'response time' and thought I'd shed some more info on the
technique...




/jf

+==========================================================+

Dijon vu: the feeling you've tasted this mustard before.

+==========================================================+