But I think we had a change, somewhere along the way from "years ago", which tipped the emphasis even further away from 'linear' and towards 'based on initial estimate'. I'll try to find it.
>________________________________ > From: "McLeod, John" <[email protected]> >To: William <[email protected]>; Oliver Bock <[email protected]>; Jon >Sonntag <[email protected]> >Cc: "BOINC Developers Mailing List @berkeley.edu" <[email protected]> >Sent: Monday, 17 February 2014, 16:19 >Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... > > >The current method works tolerably well for all projects. Strict linear based >on % complete will fail miserably for fairly high proportion of projects. > >Please note that we had this discussion years ago when we did the original >work. It was determined that straight linear based on % complete would not >work at all for some projects - therefore it was determined to be unsuitable. > >From: William [mailto:[email protected]] >Sent: Monday, February 17, 2014 11:14 AM >To: Oliver Bock; McLeod, John; Jon Sonntag >Cc: BOINC Developers Mailing List @berkeley.edu >Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... > >OK, to clarify: > >Old method: mixing project's pre-estimate with linear estimate based on what >the app reports as fraction done, according to a mixing curve that heavily >favors the project's pre-estimate early in the computation. This "old method" >should become a project opt-in. > >New method: linear estimate based on what the app reports as fraction done. >This should become the new default. > >Possible even better method: keep track of actual timing results for the last >N runs and use the average of all those to either smooth (improve the accuracy >of) or replace what the app reports as fraction done. Another opt-in (or >two), but these would be user opt-ins (vs. project opt-ins). Overrides either >the new default method or the project opt-in method (if used). > >~~~~~ >"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 Monday, February 17, 2014 10:55 AM, Oliver Bock ><[email protected]<mailto:[email protected]>> wrote: >On 17/02/14 15:39 , William wrote: >> This is exactly why linear should be the default. Dynamic should >> be available only to those projects that care enough to set it up >> properly. Linear should apply to the lazy ones unless and until >> they take the time to deliberately opt in. > >And this is where I think you got the (new) terms wrong: dynamic means >not to use any static estimates but to rely completely on what the app >reports as fraction done. This is (de facto) reliable for apps with the >said linear behavior. Bottom line: the linear option isn't the >opposite/alternative of a dynamic estimate, they go hand in hand. > > >Cheers, > >Oliver > >_______________________________________________ >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.
