Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.mel.connect.com.au!news.syd.connect.com.au!gidora.zeta.org.au!not-for-mail
From: bde@zeta.org.au (Bruce Evans)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Help! negative values from getrusage - time goes backwards
Date: 9 Jul 1996 14:17:09 +1000
Organization: Kralizec Dialup Unix
Lines: 43
Message-ID: <4rsmg5$2dh@godzilla.zeta.org.au>
References: <4rscoq$3tf@panix2.panix.com>
NNTP-Posting-Host: godzilla.zeta.org.au
In article <4rscoq$3tf@panix2.panix.com>, Paul Gallagher <pcg@panix.com> wrote:
>The getrusage system call sometimes returns values for the CPU time
>used that go backwards. I'm running FreeBSD 2.1.0 on a Pentium.
>
>My professor thinks it might be a problem in the assembly code
>for microtime in kern_clock.c inside the kernel.
There are some problems in this area with microtime(), but not in 2.1.0R.
> ssec1 = after.ru_stime.tv_sec;
> ssec2 = before.ru_stime.tv_sec;
> smsec1 = after.ru_stime.tv_usec;
> smsec2 = before.ru_stime.tv_usec;
> usec1 = after.ru_utime.tv_sec;
> usec2 = before.ru_utime.tv_sec;
> umsec1 = after.ru_utime.tv_usec;
> umsec2 = before.ru_utime.tv_usec;
> printf("system seconds (after, iterations) = %ld \n", ssec1);
> printf("system seconds (before) = %ld \n", ssec2);
> printf("system microseconds (after, iterations) = %ld \n", smsec1);
> printf("system microseconds (before) = %ld \n", smsec2);
> printf("user seconds (after, iterations) = %ld \n", usec1);
> printf("user microseconds (after, iterations) = %ld \n", umsec1);
> printf("user seconds (before) = %ld \n", usec2);
> printf("user microseconds (before) = %ld \n", umsec2);
This doesn't count the interrupt time (there are no syscalls to give the
interrupt time :-(). The kernel computes the user, system and interrupt
times from the total runtime (which is known very precisely) by
splitting up the total time in proportion to the number of user, system
and interrupt ticks. When a new tick arrives, the proportion
corresponding to the tick jumps forwards and the other 2 proportion jump
backwards. This problem is noticable mainly when the tick counts are
small. E.g. after running for 39999us, if the tick counts might be (1,
1, 1), and 1 usec later the counts might be (1, 1, 2). Then the times
jump from (13333, 13333, 13333) to (10000, 10000, 20000) - the user +
sys time apparently goes backwards by 6.67ms.
This should probably be fixed by keeping track of the last set of times
reported by getrusage() and not allowing any component of the time to
go backwards.
--
Bruce Evans bde@zeta.org.au