Kamran Karimi wrote: > Estimating proper fpops values for different work units has been a > problematic challenge for us in the AQUA project. To make things worse, > a newer version of one of our apps decides on the amount of work to be > done, based on the number of cores in the volunteer's computer on which > it runs.
The app_plan() function should tell BOINC about this; that will give both server and client a better a priori estimate of job runtime. The current interface of app_plan() doesn't allow for this (i.e. it can't modify workunit.rsc_fpops_est) If you like, I can change this. > > I wonder if it would be possible for the BOINC client to compute the > running time of an application based on the progress report as with > boinc_fraction_done(). For example, if the progress bar is at 1% after 1 > minute, then the estimated running time would be set to 100 minutes. > This estimate can change as more progress is made. This dynamic method > is probably a better way to compute the running time than fpops_est in > some projects, including ours. If already does this. If a job has been partly completed, the runtime estimate is a linear combination of static and dynamic estimates. If the fraction_done is X, the weight of the static estimate is (1-X)^2, to quickly give more weight to the dynamic estimate. In recent clients, the exponent was changed from 2 to 3 to increase this effect. The reason for not using the dynamic estimate exclusively is that many applications do not supply an accurate fraction_done() during their startup phase. -- David _______________________________________________ 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.
