Date: Mon, 31 Jan 2005 22:47:05 -0800 (PST) From: Chris Landauer <cal@rush.aero.org> To: ambrisko@ambrisko.com, truckman@freebsd.org Cc: cal@rush.aero.org Subject: Re: bug in calcru() - the clock is ticking Message-ID: <200502010647.j116l59R095780@calamari.aero.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502010647.j116l59R095780>