I have been thinking, and a temporary DCF might help with startup problems, however, I believe it should be done a bit differently than the recent experiment.
If a DCF is needed, make a temporary copy of the current DCF for each project. Add the current estimate for each task that is partly complete to the temporary DCF using the same algorithm as is used to add completed tasks to the DCF. For projects where the fpops_est is extremely low, this will help avoid some of the work fetch that occurs before the first task is completed. Later in life of the project, the impact is not likely to be as large. I would like to suggest that using the mean and standard deviation for DCF might be more stable later in the project lifetime. I would also suggest that using the app version and fpops_est as keys to look up the current DCF for a task would also be a good idea. This would lead to a heirarchy of DCF values to be used if a a lower level DCF is unknown. If you have a DCF for a project, app version, fpops_est that is valid (for statistics based, count > 1 is valid), use that. else if you have a DCF for a project, app version that is valid, use that. else if you have a DCF for a project, that is valid, use that. else use the value 1. This means that new projects would assume the value 1. A new app would use the project base DCF, and a new fpops_est would use the base for the app version. jm7 _______________________________________________ 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.
