# bug in calcru()

Chris Landauer cal at rush.aero.org
Wed Jan 26 13:06:22 PST 2005

```hihi, doug -

> Doug Ambrisko <ambrisko at ambrisko.com> wrote
>	...
>	The assumption with this calculation is that st & it tend to be
>	small compared to tt so the 1024 X shouldn't overflow much.
>	...
> cal at aero.org wrote:
> |	...but i'm a little worried that the 1024 multiplications aren't
> |	large enough when tt gets really large
> | > Doug Ambrisko <ambrisko at ambrisko.com> wrote
> | >     ...
> | >     /* Subdivide tu. try to becareful of overflow */
> | >     su = tu * (st * 1024 / tt) / 1024;
> | >     iu = tu * (it * 1024 / tt) / 1024;
> | >     uu = tu - (su + iu);
> | >     ...

i'm not so worried about the overflow limit (that's what the mathematical
analysis is intended to discover, and i assume that the bound is large enough
to ignore the issue - that is the really clever part about computing su and iu
first instead of uu), but the underflow - if st and it are small enough and tt
is large enough, these equations produce 0 for both su and iu (and the
reported percentage will rightly be 0.00%, but i want to see the rest of the
detail for my time models)

what i think i'll do is try out my set of if-protected equations, but with
your choice of computing su and iu - that ought to avoid both problems

#define TOOBIG 45254834 /* 32*sqrt(2)*10^6 */
if (tt >= TOOBIG && tu >= tt)
{
u_int64_t q, r;
q = tu / tt;
r = tu % tt;
su = (q * st) + (r * st) / tt;
iu = (q * it) + (r * it) / tt;
}
else	{
su = (tu * st) / tt;
iu = (tu * it) / tt;
}
uu = tu - (su + iu);

of course, JUST using the lines

su = (tu * st) / tt;
iu = (tu * it) / tt;
uu = tu - (su + iu);

will help a lot already - perhaps this much should be done right now
(according to the usual committment protocols) while we analyze the various
alternative suggestions for improvement (or are there high-utilization
processes that are more system time than user time?)

general question - is it (interrupt time) where the unreported time is when
user and system percentages add up to much less than 100%? i assume that the
monotonicity rules are what makes programs report over 100% utilization (which
i get occasionally, but only on very short programs)

more later,
cal

Chris Landauer
Aerospace Integration Science Center
The Aerospace Corporation
cal at aero.org

PS - i'm sorry i don't speak "patch" well enough yet, but i will eventually

```