[Info-vax] High resolution per-process CPU consumption statistics
Mark Daniel
mark.daniel at wasd.vsm.com.au
Sat Mar 28 18:31:59 EDT 2020
On 29/3/20 7:38 am, hb wrote:
> On 3/28/20 5:02 PM, Mark Daniel wrote:
>> 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.
>
> Very large numbers? As far as I know the counter you want is a 32-bit
> value. Did you do the shifts and add? I assume they are explained in the
> Alpha architecture manual.
>
> #include <stdio.h>
> #include <unistd.h>
> #include <builtins.h>
>
> int main(void) {
> unsigned __int64 pcc;
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> printf ("sleep(1)\n");
> sleep(1);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> printf ("sleep(4)\n");
> sleep(4);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc= ((pcc<<32)+pcc)>>32;
> printf ("0x%016llx\n", pcc);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc= ((pcc<<32)+pcc)>>32;
> printf ("0x%016llx\n", pcc);
> printf ("sleep(1)\n");
> sleep(1);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc= ((pcc<<32)+pcc)>>32;
> printf ("0x%016llx\n", pcc);
> printf ("sleep(4)\n");
> sleep(4);
> pcc=__RPCC();
> printf ("0x%016llx\n", pcc);
> pcc= ((pcc<<32)+pcc)>>32;
> printf ("0x%016llx\n", pcc);
> return 0;
> }
(some of my following edit is quoted to prevent wrapping)
Not using the PAL code instruction directly. Using the $RPCC_64 system
service. On Alpha this performs the required bit fiddling on Alpha (but
presumably introduces its own overhead) and conjures up an equivalent
with IPF.
> OpenVMS System Services Reference Manual (V8.4): $RPCC_64:
>
> "On Alpha and I64 systems, returns a 64-bit long version of the current process
> cycle counter. On Alpha systems, this service must be called at least once
> within each wrap period of the least significant 32 bits of the counter. For
> more information, see the RPCC() C-language built-in documentation and the RPCC
> instruction in the Alpha Architecture Handbook."
The Alpha Architecture manual emphasises the 32 bit nature of the PCC
and usage timing considerations.
Snippets from my codebase:
unsigned __int64 drpcc64, rpcc64;
...
/* apparently context is unnecessary but innocuous from Alpha V8.4 */
rpcc64 = sys$rpcc_64 (&ctx64);
...
/* delta from initial */
drpcc64 = rpcc64 - init64;
...
using $FAO to output 64 bit values - !@SQ
...
The actual code keeps a history (array) of up-to 8 code-points (of which
the following output snippet showd two in use). The actual routine is
too complex to post here but here are examples of some of the numbers
coming out.
> |08:38:43.35 NETIO 0461|RPCC 2 5,624,296,091 [0]1,930,847(0.0%) [1]13,502,718(699.3%) [2]1,930,847(100.0%)
> |08:38:43.35 NETIO 0461|RPCC 2 5,625,157,213 [0]861,122(0.0%) [1]14,363,840(1668.0%) [2]861,122(100.0%)
> |08:38:43.35 NETIO 0461|RPCC 2 5,626,476,353 [0]1,319,140(0.0%) [1]15,682,980(1188.9%) [2]1,319,140(100.0%)
> |08:38:43.36 NETIO 0461|RPCC 2 5,628,652,236 [0]2,175,883(0.0%) [1]17,858,863(820.8%) [2]2,175,883(100.0%)
> |08:38:43.37 NETIO 0461|RPCC 2 5,631,158,788 [0]2,506,552(0.0%) [1]20,365,415(812.5%) [2]2,506,552(100.0%)
> |08:38:43.37 NETIO 0461|RPCC 2 5,634,506,708 [0]3,347,920(0.1%) [1]23,713,335(708.3%) [2]3,347,920(100.0%)
> |08:38:43.38 NETIO 0461|RPCC 2 5,637,844,884 [0]3,338,176(0.1%) [1]27,051,511(810.4%) [2]3,338,176(100.0%)
The first big number is the 64 bit RPCC value since initialisation, the
[0] the delta since last report of that value, ignore the [1]
(collection code-point requires adjustment), the [2] represents a tight
block of processing. To emphasize, the first big number is raw 64 bit
from $RPCC_64.
The output seems to be representative.
More information about the Info-vax
mailing list