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]> 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.
