In the record returned by pstat_getproc() - how is pst_cpupct calculated?

[John Wikoff]

pm_pstat_body.h shows:

float pst_pctcpu;/* %cpu for this process during p_time */

The comment suggests that tthe value is the average CPU utilization over a window of time called "p_time".

>> What is p_time (or where is it defined)?

The behavior of the value suggests that it may actually decay rather than be a straight average.

>> How is pst_pctcpu calculated?

I want to calculate CPU utilization for a window of my choosing (generally 1 sec)

>> Is the delta of pst_cptickstotal divided by time my best bet?

If I was so inclined, I'm guessing I could calculate it with more precision my tapping pst_usercycles, pst_systemcycles and pst_interruptcycles

>>What do those fields count - actual intruction cycles in each mode?

Sorry for the flurry of questions, but the comments in the header are about all I have to go on.   I can't find ANY documentation...

- John

[Dennis Handly]

> What is p_time (or where is it defined)?

Have you grepped other headers?  Does it really matter?

What are you really trying to do?

>The behavior of the value suggests that it may actually decay rather than be a straight average.

Why would it be anything but an average?  But there is a decay of the process priority that may make it seems like the % does decay.

[John Wikoff]

It must, of course, be an average, but the value (p_time) seems to be a fairly large window of time.  I've not been able to find any reference to "p_time" anywhere else, but watching the cpu value in top, pst_cpupct stays in sync.  I have a process which goes to a fairly stable usage of 2% cpu after running for about 10 seconds, yet according to top, it decays from about 8% to 2% over a period of about 1-2 minutes - a huge lag when trying to measure process response.

I want a value over a second, so I can get a fairly accurate indication of a spike in utilization, and when that utilization falls of, so I can correlate the cpu usage with other events on the system.  For that use, pst_cpupct seems inappropriate.

I've been able to infer that the delta of  pst_usercycles+pst_systemcycles+pst_interruptcycles would indicate actual process usage (over whatever window I choose for my delta).  I've found no documentation confirming that though.  In fact the term "cycle" is used out of hand without explanation - is a cycle a CPU/instruction cycle?  

psp_iticksperclktick appears to give a precise measurement of iticks ('Instruction ticks"? )

Are these at a rate of 1 itick per cycle?

[Dennis Handly]

>but the value (p_time) seems to be a fairly large window of time.  I've not been able to find any reference to "p_time" anywhere else, but watching the cpu value in top, pst_cpupct stays in sync

It stays in sync with top, since that's what top uses.  :-)

If you look at the 11.31 header it says:     %cpu for this process(smoothed)

>psp_iticksperclktick appears to give a precise measurement of iticks (Instruction ticks?)

>Are these at a rate of 1 itick per cycle?

I would assume so,

[John Wikoff]

It's smoothed alright, right over any semblance of reality.  If my process is chewing up 10% CPU and suddenly drops to 1%, it takes nearly 2 full minutes before top gets around to displaying 1%.  Email would be more timely.

My tests seem to indicate that measuring delta in pst_*cycles and dividing by (psp_iticksperclktick * CLOCKS_PER_SEC * seconds_elapsed) gives the right value.  The only thing that would throw this off is if a CPU architecture allowed multiple cycles per itick.  (My hope is that psp_iticksperclktick  would transparently reflect such an architecture)

[John Wikoff]

small correction:

CLOCKS_PER_SEC should have been sysconf(_SC_CLK_TCK), so cycles per second would be:

psp_iticksperclktick*_SC_CLK_TCK