I'd prefer to figure out why the static estimates are off. If an app's jobs are of a size proportional to wu.rsc_fpops_est, the static estimates should be almost exact, even for a host's first jobs. If there's a bug, let's fix it rather than hide it. -- D
On 13-Feb-2014 10:41 PM, Rytis Slatkevičius wrote:
This is exactly why Jon and Mike are proposing two different modes of runtime estimation: for linear projects (probably applications only, as a project can have multiple apps), add a flag to mark the application as linear; the remaining projects would use the same method as now. Since the new developers probably won't know about the flag, the current estimate should be the default. David, I want to make sure: is it that you oppose the suggestion itself, or is the time constraints that stop you from implementing it? If the latter, we could submit patches. -- Pagarbiai / Sincerely Rytis Slatkevičius +370 670 77777 On Fri, Feb 14, 2014 at 4:54 AM, David Anderson <[email protected] <mailto:[email protected]>> wrote: I want to make sure everyone realizes that some apps inherently can't supply an accurate fraction done. It's easy if your app has the form for i=1,N fixed computation It not easy if your app has the form lengthy preprocessing for i=1,n fixed computation lengthy postprocessing or while true do fixed computation if convergence criterion met break _________________________________________________ boinc_dev mailing list [email protected] <mailto:[email protected]> http://lists.ssl.berkeley.edu/__mailman/listinfo/boinc_dev <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.
