time and timing errors in c code on 5.x/i386 (longish)

[Don Lewis]

On 23 Jan, Peter Jeremy wrote:
> On Fri, 2005-Jan-21 14:49:41 -0800, Chris Landauer wrote:
>>i'm running some combinatorial search programs that take weeks or months to
>>complete, and no timer i've used is able to report correctly the user and
>>system time (they all make the same mistake - eventually the user time stops
>>incrementing) - i want precise times to do some predictive modeling
> 
> [evidence deleted]
> 
> The problem looks like an overflow error in calcru().  Have you seen any
> kernel messages beginning 'calcru:'?

I haven't on my 4.x machine.

> The offending code is:
>         uu = (tu * ut) / tt;
> where all variables are uint64
>   uu is the user time in microseconds (that will be converted to a timeval
>      and reported via getrusage())
>   tu is the total usermode runtime allocated to your program (in usec)
>   ut is the number of usermode statclock hits (128Hz)
>   tt is the total (user+sys+int) statclock hits.
> 
>>user 378925.483628 syst 286.845375 elapse 381328.785295 pct 99.44%
>>user 379089.748458 syst 286.962284 elapse 381493.700660 pct 99.45%
>>user 379255.472355 syst 287.088004 elapse 381660.106387 pct 99.45%
>>user 379417.184286 syst 287.190223 elapse 381822.457863 pct 99.45%
>>user 379417.184286 syst 451.110470 elapse 381986.906692 pct 99.45%
>>user 379417.184286 syst 615.737725 elapse 382152.058304 pct 99.45%
> 
> At this point tu is roughly 379417184286 and ut is roughly 48565399
> The product is about 1.8e19 - which is roughly 2^64.
> 
> That particular code goes all the way back to BSD4.4lite so it's a bug
> that has always existed.  We can't use FP in the kernel and don't
> support 128-bit integers (or arithmetic) anywhere so a correct fix is
> quite ugly (and inefficient) in portable C.

I think this explains why setiathome thinks it has stopped accumulating
CPU time after a while.  I've mostly noticed this on my 4.x machine
because it runs 24x7 and tends to have long uptimes.