Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jan 2005 13:05:59 -0800 (PST)
From:      Chris Landauer <cal@rush.aero.org>
To:        ambrisko@ambrisko.com
Cc:        cal@rush.aero.org
Subject:   Re: bug in calcru()
Message-ID:  <200501262105.j0QL5x9W042384@calamari.aero.org>

next in thread | raw e-mail | index | archive | help

hihi, doug -

> Doug Ambrisko <ambrisko@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@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@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@aero.org

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501262105.j0QL5x9W042384>