10-21-2011 10:07 AM
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...
10-21-2011 05:27 PM
> 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.
10-25-2011 01:42 PM
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_interruptcycl
psp_iticksperclktick appears to give a precise measurement of iticks ('Instruction ticks"? )
Are these at a rate of 1 itick per cycle?
10-25-2011 09:23 PM
>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,
10-26-2011 06:51 AM
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)
10-26-2011 01:37 PM
CLOCKS_PER_SEC should have been sysconf(_SC_CLK_TCK), so cycles per second would be: