I don't know what percentage of apps behave this way, but certainly many apps behave in a completely linear fashion. If they're reporting x% complete, then the time they've used will be exactly x% of of the total run time. Everything at PrimeGrid behaves like this; After just a few minutes of running we can generally predict the total run time with an accuracy of about 99%. To be sure this doesn't apply to all projects, but it certainly applies to some and possibly is true for most.
If the BOINC client ignored it's own static time calculation and simply used the percentage complete and the cpu_time (or elapsed time in the case of GPU apps), wouldn't it almost always show an accurate time estimate? If an app (or perhaps app_version) could be designated as "linear", and the client used this flag to weight the dynamic calculation at 100% and ignore the static calculation, I think the estimated time problem would vanish for a significant number of projects. Mike On Sun, Feb 9, 2014 at 8:46 AM, William <[email protected]> wrote: > As Jon pointed out, it's very embarrassingly inaccurate early in the run. > > The negative exponential weighting of the dynamic estimate is the problem. > > Suggest weighting the dynamic estimate as: > > MAX (1, (3 * the PERCENTAGE done)) > > Then at 11% the weight of the dynamic estimate is 33% (vs. 1.21%). > > > ~~~~~ > "Rightful liberty is unobstructed action according to our will within > limits drawn around us by the equal rights of others. I do not add 'within > the limits of the law' because law is often but the tyrant's will, and > always so when it violates the rights of the individual." - Thomas Jefferson > > > > On Saturday, February 8, 2014 8:44 PM, David Anderson < > [email protected]> wrote: > > The estimate is a weighted combination of > >static (based on wu.rsc_flops_est and avp->flops) > >and dynamic (based on fraction done and elapsed time) > >estimates; see below. > >The weight of the dynamic estimate is the square of the fraction done; > >e.g. when 50% done, the weight is 0.25. > > > >So at 11% done the estimate is based almost entirely on the static > estimate. > > > >-- David > > > >double ACTIVE_TASK::est_dur() { > > if (fraction_done >= 1) return elapsed_time; > > double wu_est = result->estimated_runtime(); > > if (fraction_done <= 0) return wu_est; > > if (wu_est < elapsed_time) wu_est = elapsed_time; > > double frac_est = fraction_done_elapsed_time / fraction_done; > > double fd_weight = fraction_done * fraction_done; > > double wu_weight = 1 - fd_weight; > > double x = fd_weight*frac_est + wu_weight*wu_est; > > return x; > >} > > > >double RESULT::estimated_runtime_uncorrected() { > > return wup->rsc_fpops_est/avp->flops; > >} > > > >// estimate how long a result will take on this host > >// > >double RESULT::estimated_runtime() { > > double x = estimated_runtime_uncorrected(); > > if (!project->dont_use_dcf) { > > x *= project->duration_correction_factor; > > } > > return x; > >} > > > > > >On 08-Feb-2014 11:54 AM, Jon Sonntag wrote: > >> Why would 11% complete in 1.5 hours have an estimated 72 hours remaining > >> when it should be closer to 14 hours remaining? Does BOINC need a math > >> tutor? ;-) > >> > >> I find it interesting that the estimates on a Q6600 are correct but on > both > >> of my i7 hosts they are way too high. > >> > >> All hosts have all been running the app for several weeks so any > learning > >> curve by the smart estimate algorithm should have adjusted the numbers > >> already, right? How long should it take BOINC to get the estimates > >> correct? I would think less than an hour when percent complete is > totally > >> linear. Or is the problem the that the benchmarks do not take into > account > >> hyper-threading which skews the estimates? > >> > >> Jon Sonntag > >> _______________________________________________ > >> boinc_dev mailing list > >> [email protected] > >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > >> To unsubscribe, visit the above URL and > >> (near bottom of page) enter your email address. > > > >> > >_______________________________________________ > >boinc_dev mailing list > >[email protected] > >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > >To unsubscribe, visit the above URL and > >(near bottom of page) enter your email address. > > > > > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
