From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 1 06:47:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8FF016A4CE; Tue, 1 Feb 2005 06:47:31 +0000 (GMT) Received: from mhultra.aero.org (mhultra.aero.org [130.221.88.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B4C643D1F; Tue, 1 Feb 2005 06:47:31 +0000 (GMT) (envelope-from cal@rushg.aero.org) Received: from rushe.aero.org ([130.221.24.10] [130.221.24.10]) by mhultra.aero.org with ESMTP; Mon, 31 Jan 2005 22:47:25 -0800 Received: from calamari.aero.org (calamari.aero.org [130.221.26.26]) by rushe.aero.org (8.11.7p1+Sun/8.11.7) with ESMTP id j116lO524899; Mon, 31 Jan 2005 22:47:24 -0800 (PST) Received: from calamari.aero.org (localhost [127.0.0.1]) by calamari.aero.org (8.12.11/8.11.6) with ESMTP id j116l69H095781; Mon, 31 Jan 2005 22:47:06 -0800 (PST) (envelope-from cal@calamari.aero.org) Received: (from cal@localhost) by calamari.aero.org (8.12.11/8.12.11/Submit) id j116l59R095780; Mon, 31 Jan 2005 22:47:05 -0800 (PST) (envelope-from cal) Date: Mon, 31 Jan 2005 22:47:05 -0800 (PST) From: Chris Landauer Message-Id: <200502010647.j116l59R095780@calamari.aero.org> To: ambrisko@ambrisko.com, truckman@freebsd.org X-Mailman-Approved-At: Tue, 01 Feb 2005 13:23:53 +0000 cc: freebsd-hackers@freebsd.org cc: cal@rush.aero.org Subject: Re: bug in calcru() - the clock is ticking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 06:47:31 -0000 hihi, all - i am currently running the experiment with both suggestions - doug's one of simply re-ordering the equations, and my more complicated one with the conditional (and the re-ordering) - the first significant data point will come tomorrow, when the test cpu times pass the first error threshold of the current set of equations i will report the experimental results as i get them - a full description of the analysis and experimental activities can be found on the web (and will be updated as i get more results, generally every day or two, until the two programs diverge in behavior, or i get tired of it) http://www.cs.umd.edu/~cal/math/overflow-analysis.txt it seems quite clear to me that just re-ordering the equations (part of doug's original suggestion) would be a very good interim fix - it would clearly not change any of the timing or values computed for short programs, and would only affect programs that are high-usage for long times, making user programs fail later, and system programs fail sooner (if there are any) i asked before (does anybody know the answer?) - are there long running, high utilization programs that are mostly system time? or mostly interrrupt time? if not, then i recommend the re-ordering fix until the results of the analysis and the experiments are in more soon, cal Chris Landauer Aerospace Integration Science Center The Aerospace Corporation cal@aero.org