> The only mechanism for changing it is to modify the duration correction > factor. The duration correction factor will correct itself over time > anyway, but it is possible to set it by hand to be closer to where it will > eventually stabilize. > > jm7
The problem with relying on DCF is that no adjustment to DCF is made until a task completes, even if the initial estimate is drastically low - so all calculations which rely on DCF, like work fetch, do not start to self-correct until it's too late. A case in point: I have been in extended conversation with the administrator of the AQUA project. They are issuing test workunits of varying duration, but haven't got the hang of adjusting <rsc_fpops_est> to ensure BOINC has something to base its estimates on. I'm seeing the same estimate for everything from 8-!M (15 minutes) to 240-5M (280 hours). The latter equates to a DCF of around 200, which is going to be a problem: but I have a host running one of these where the DCF is still below 8 from earlier, smaller tests, and presumably the DCF won't be corrected for the best part of a fortnight. Of course, it would be better if all BOINC projects made at least a reasonable attempt at adjusting their work estimates, but not everyone does this - and I've singularly failed to persuade AQUA to join the ranks of the ones that do. I believe David has been in touch with this project - perhaps you could have a word? [ Does anyone run training courses for new BOINC administrators? ] But back to DCF - if DCF could be edged upwards incrementally once the elapsed runtime has exceeded the initial estimate, it would help to avoid excessive work fetch on unruly projects. _______________________________________________ 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.
