"... the time spent already (the only really well known item in the list) ..."
Which is why I'd like to see greater weight given to this in the displayed estimate. It seems the be the wrong way round, to distort the displayed figures for "well-behaved" (in the mathematical sense) projects, just because a minority of projects can't predict runtime in advance. It would be better if BOINC left project problems to the projects concerned, and concentrated on the things which only BOINC can get right - and the initial estimates for new hosts (and hence possibly new volunteers) would seem to be a higher priority. It's subjective, but I seem to have seen a lot of posts on message boards by new volunteers who come close to aborting tasks, even abandoning the project entirely, because there seems to be no way of completing the initial task(s) within deadline. Jon's comparison of Q6600 and i7 should remind us that the Whetstone benchmark was originally "designed to defeat compiler optimizations" (Wikipedia) - and hence will also defeat hardware optimisations like SIMD and AVX, also not present on a KDF9. The initial estimate for a CPU application needs to be based on real-world scientific throughput in the 21st. century, and for a GPU application on an assessment of the speed of the GPU in question (not, as at present, on a multiplier of the host CPU). >________________________________ > From: "McLeod, John" <[email protected]> >To: Jon Sonntag <[email protected]>; "BOINC Developers Mailing List >@berkeley.edu" <[email protected]> >Sent: Monday, 10 February 2014, 13:48 >Subject: Re: [boinc_dev] Estimated Time Remaining > > >Not all applications report smooth % complete. So the calculation of time >remaining involve the initial estimate as well. Given the bad information >given for both % complete and initial estimate, there is no method of >predicting how much longer the task will take that is completely right. The >most reliable appears to be to combine the initial estimate the DCF (if in use >for the project) the % complete, and the time spent already (the only really >well known item in the list) to come up with an estimate. > >-----Original Message----- >From: boinc_dev [mailto:[email protected]] On Behalf Of Jon >Sonntag >Sent: Saturday, February 08, 2014 2:54 PM >To: BOINC Developers Mailing List @berkeley.edu >Subject: [boinc_dev] Estimated Time Remaining > >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.
