** Reply to message from "Robert Gammon" <rgammon51@xxxxxxxxx> on Wed, 10 May
2006 18:03:55 -0000
>My XP machine has the enhanced client on it.
>
>Est Total Time has EXPLODED!
>
>Now it appears that an enhanced WU is alos being processed. Est Totla
>Time has EXPLODED to 31 hours, and benchmarks are showing 1050 MOPs.
>With just under 11 hours of execution and 3 hours estimated time
>remaining at 80% complete, the 31 hour figure seems farcical
>
The "Est. Total Time" and "Time to go" have always been problematic for JBSWU.
I'm not sure they will ever be reliably accurate. I think
"reasonable-estimate-based-on-available-information" is a better way to
describe them.
"Est. Total Time" is calculated directly from values retrieved from --get_state
in the following way:
rsc_fpops_est * p_fpops / duration_correction_factor
"Time to go", a value much discussed during the early development of JBSWU, is
calculated in the following way:
CPU_time * % done + (Est. Total Time - CPU_time) * (1 - % done)
During the earlier discussion of "Time to go" I was informed that not all
stages of a workunit are the same. For example, the processing done at the 5%
mark may be much different than the processing at the 27% mark, etc and these
differences might mean that the time necessary to proceed from 5% to 6% may be
quite different from the time needed to proceed from 27% to 28%.
I have found discrepancies like your describe...
>With just under 11 hours of execution and 3 hours estimated time
>remaining at 80% complete, the 31 hour figure seems farcical
even before the advent of enhanced client workunits so I do not think that
these new workunits are a factor in what you have observed.
Improved "Est. Total Time" and "Time to go" can be achieved by:
1) Improved formulas for calculation: I am open to continued discussion
of
better formulas.
2) More accurate information used within these formulas: This may
require
someone who knows the client software and can tell us how to retrieve better
data and/or change the client to provide more accurate information. For
example I think that the "fraction_done" is not a fraction of time but of some
other quantity which does not linearly map to time.
3) Less discrepancy between benchmark figures and "real life" figures:
Perhaps if we ran benchmarks during "normal" times (instead during idle time
and/or after a "cool-off-the-processor" shutdown), the time estimates would be
more accurate.
--
John Small
------------------------ Yahoo! Groups Sponsor --------------------~-->
You can search right from your browser? It's easy and it's free. See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/9rHolB/TM
--------------------------------------------------------------------~->
|
