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 <da...@ssl.berkeley.edu>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 > boinc_dev@ssl.berkeley.edu > 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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
