lkml.org 
[lkml]   [2007]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectgetrusage time measurements variations
Hello all,
I've been doing some getrusage tests using this:

#include <stdio.h>
#include <unistd.h>
#include <sys/resource.h>

int main(void)
{
unsigned int i;
struct rusage ru;
for(i=1;i;i++) asm volatile("nop");
getrusage(RUSAGE_SELF, &ru);
printf("%dsec %dusec\n",ru.ru_utime.tv_sec,ru.ru_utime.tv_usec);
return 0;
}

What is good is that results do not seem to depend on other thread
activity nor disk i/o. However, each time I run this program, result
varies (from 4.039 sec to 4.062 sec). Does the actual execution time
change each time? User time should not contain .so library loading
time, nor memory allocation time (kernel part) nor anything like this.
Does getrusage measure time so accurately (1usec precision), even if
HZ is set to, let's say, 100?

But that's not very bad... Problems start, when I run this with heavy
network i/o load. I'm using ne1000 network adapter (on isa bus...
well, that's very old stuff), which seem to generate interrupt on each
packet it receives - top reports very high "hi" values, up to 20%.
Results from getrusage change to 5.2 sec. Is this variation the same
one as above, but in greater scale? Can this be eliminated?

My problem is, that I'd like to measure user time of process with
1msec resolution, but what is most important, I want the result to be
the same each time I run program. Can it be done with standard linux
kernels, or should I try some "real-time" versions?

Thanks for responses, and please CC me, I'm not in the list.
--
wixor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-08 20:23    [W:0.023 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site