Yes. The original was a linear combination, the new is based on squares. From: Richard Haselgrove [mailto:[email protected]] Sent: Monday, February 17, 2014 11:34 AM To: McLeod, John; William; Oliver Bock; Jon Sonntag Cc: BOINC Developers Mailing List @berkeley.edu Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...
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]<mailto:[email protected]>> To: William <[email protected]<mailto:[email protected]>>; Oliver Bock <[email protected]<mailto:[email protected]>>; Jon Sonntag <[email protected]<mailto:[email protected]>> Cc: "BOINC Developers Mailing List @berkeley.edu" <[email protected]<mailto:[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]<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]><mailto:[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]<mailto:[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.
