Just some brief thoughts: (Sorry if I'm stating the obvious, I'm just trying to be clear about assumptions.)
My understanding for the credits are that they are primarily to encourage user participation by showing a 'reward' and to offer a means for competition to encourage further participation; Whether intended or not, the credits are also used as a performance measure for Boinc as a whole, for individual projects, and by users; The units used for the Boinc credits can be arbitrary. To avoid user frustrations, the credits need to be consistent, non-inflationary, and above all seen to be "fair". So... How do optimised applications fit in with the credits scheme? If a project task can now be done in less time by an optimised application, compared to previously for the same task, is the same credit or less credit (due to less resource time used) to be awarded for that one task? How does that work for the credits for the same task run on different hardware, where one set of hardware is much more efficient/faster than the other for that task? For cases where validation is allowed for a task run across different hardware, I personally feel that the credits calculations should reliably come close the same number for any hardware for that one task... Or should that not be the case? Personal thoughts: I once favoured the idea (Eric's?) of scheduling using client computed RAC so that the resource shares would share the credits in the way the users had set by the resource share. However, a big assumption to allow that to work well is that everything is calibrated so that: credits are directly proportional to compute resources used However, is not the "compute resource used" actually: k * "time the resource is utilised" where "k" is dependant on each individual project application and the efficiency of the resource utilisation for that individual application (and even for the dataset being processed)? Hence, "k" is NOT a constant! Hence, to include "k" in the scheduling gives the scheduler an ever moving target... Regards, Martin -- -------------------- Martin Lomas m_boincdev ml1 co uk.ddSPAM.dd -------------------- _______________________________________________ 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.
