In Perl module Proc::ProccessTable, why does pctcpu sometimes return 'inf', 'nan', or a value greater than 100?

Question

The Perl module Proc::ProcessTable occasionally observes that the pctcpu attribute as 'inf', 'nan', or a value greater then 100. Why does it do this? And are there any guidelines on how to deal with this kind of information?

We have observed this on various platforms including Linux 2.4 running on 8 logical processors.

I would guess that 'inf' or 'nan' is the result of some impossibly large value or a divide by zero.

For values greater then 100, could this possibly mean that more then one processor was used?

And for dealing with this information, is the best practice merely marking the data point as untrustworthy and normalizing to 100%?

Answer 1

I do not know why that happens and I cannot stress test the module right now trying to generate such cases.

However, a principle I have followed all my research is not to replace data I know to be non-sense with something that looks reasonable. You basically have missing observations and you should treat them as such. I would not attach a numerical value at all so as not to pretend I have information when I in fact do not.

Then, your statistics for the non-missing points will be meaningful and you can look at any patterns in the missing observations separately.

UPDATE: Looking at the calc_prec() function in the source code:

/* calc_prec()
 * 
 * calculate the two cpu/memory precentage values
 */
static void calc_prec(char *format_str, struct procstat *prs, struct obstack *mem_pool)
{
    float pctcpu = 100.0f * (prs->utime / 1e6) / (time(NULL) - prs->start_time);

    /* calculate pctcpu - NOTE: This assumes the cpu time is in microsecond units! */
    sprintf(prs->pctcpu, "%3.2f", pctcpu);
    field_enable(format_str, F_PCTCPU);

    /* calculate pctmem */
    if (system_memory > 0) {
        sprintf(prs->pctmem, "%3.2f", (float) prs->rss / system_memory * 100.f);
        field_enable(format_str, F_PCTMEM);
    }
}

First, IMHO, it would be better to just divide by 1e4 rather than multiplying by 100.0f after the division. Second, it is possible (if polled immediately after process start) for the time delta to be 0. Third, I would have just done the whole thing in double.

As an aside, this function looks like a good example of why you should not have comments in code.

#include <stdio.h>
#include <time.h>

volatile float calc_percent(
        unsigned long utime,
        time_t now,
        time_t start
) {
    return 100.0f * ( utime / 1e6) / (now - start);
}

int main(void) {

    printf("%3.2f\n", calc_percent(1e6, time(NULL), time(NULL)));
    printf("%3.2f\n", calc_percent(0,   time(NULL), time(NULL)));

    return 0;
}

This outputs inf in the first case and nan in the second case when compiled with Cygwin gcc-4 on Windows. I do not know if this behavior is standard or just what happens with this particular combination of OS+compiler.