[Info-vax] High resolution per-process CPU consumption statistics

[Mark Daniel]

On 25/3/20 8:42 am, Mark Daniel wrote:
> On 25/3/20 7:58 am, johnwallace4 at yahoo.co.uk wrote:
>> On Tuesday, 24 March 2020 17:05:24 UTC, Mark Daniel  wrote:
>>> On 24/3/20 9:24 pm, johnwallace4 at yahoo.co.uk wrote:
>>>> On Tuesday, 24 March 2020 00:02:22 UTC, Mark Daniel  wrote:
>>>>> Would like to be able to measure process CPU consumed during specified
>>>>> continuous sections of processing.  Only interested in CPU-intensive
>>>>> sections so USER mode consumed relevant.  Imagine inserting calls 
>>>>> at the
>>>>> beginning and ending of those sections with a magic number 
>>>>> representing
>>>>> CPU consumption/delta/whatever made available.
>>>>>
>>>>> As some of these CPU-intensive code sections are short duration the
>>>>> granularity needs to be quite fine.  The likes of JPI$_CPUTIM and
>>>>> LIB$STAT_TIMER (10mS) seem unsuitable.
8< snip 8<
>> Can you say a little more about what you're trying to
>> achieve here? It may not be appropriate to extrapolate
>> results among different members of the Alpha family,
>> never mind from one processor architecture to a very
>> different one (Alpha->IA64?). Maybe that doesn't
>> matter?
> 
> Understanding the *proportional* overhead of cryptographic processing on 
> top of everything else will be sufficiently fit-for-purpose.  Absolute 
> metrics much less important.
> 
> And it could be done by measuring the time /n/ transactions unencrypted 
> vs the same number encrypted took to process but I thought I'd try this 
> first.  Might even show some portions more intensive than others.
> 
> Thanks again Brian and John.
> 
>> Have a lot of fun.
> 
> Trying.

A brief update:  On Alpha V8.3 and PWS500.  The SYS$RPCC_64 call works 
and returns some *very* large numbers/deltas even inside otherwise 
single 10mS time intervals.  Some code wrapped around it provides those 
deltas and the percentages of totals.  Perversely, it seems a little too 
fine-grained for my initial needs.  Would be perfect for comparing 
efficiencies of alternate tight code blocks.  Might be heading back in 
the direction of /n/ transaction comparisons but will to continue to 
experiment.