From owner-freebsd-bugs Tue Apr 25 11:42:44 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 2A2DC37B5C3 for ; Tue, 25 Apr 2000 11:42:34 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 2237 invoked from network); 25 Apr 2000 18:42:25 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 25 Apr 2000 18:42:25 -0000 Date: Wed, 26 Apr 2000 04:42:21 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Kees Hendrikse Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/17842: Erratic user time reports for long running processes In-Reply-To: <200004250840.BAA70268@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What baffles me most: why stop counting at 379265,687860 seconds? The multiplication in "uu = (tu * ut) / tt;" in kern_resource.c overflows near there. Here tu is the total time in usec, ut is the user tick count and tt is the total tick count. If all ticks are user ticks, then overflow occurs for tu = sqrt(2^64 / 10^6 / hz) = 429496 seconds when hz = 100. Normally there are some interrupt and system ticks, so overflow occurs for a somewhat larger tu and a somewhat smaller ut -- apparently about 379 / 429 times smaller in your case. 4.0 enforces monotonicity of the resource times, so truncated values resulting from the overflow don't cause the resource times to stick at the first value where overflow occurs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message