> > If a project has highly variable jobs, this translates into highly > variable credit > > And this is probably what Richard is pointing out as the core of the > problem. People see this as a flaw in the credit system - and I have to > agree to some extent that credit consistency within a single project at > any given time is a very important treat in a credit system. > Long term and even cross-project credit stability is desirable, but if > it comes at the cost of short term credit stability then we have to > consciously weigh them against each other and figure out what is more > important to us. > People perceive instability (be that short or long term) as "unfair".
Well, up to a point. I deliberately opened this thread with a report about server-side work over-allocation, although as runtime estimation and CreditNew are intimately bound together, it made sense to port the credit observations into the same discussion. I regard BOINC as having dual objectives: 1) To provide a general open-source infrastructure for scientific research, to a quality and standard of reliability that satisfies the needs of the scientific research community. 2) To recruit and retain volunteers (and their computers) to provide computational resources as needed by that community. Credit, and the other social elements (message boards, teams, etc.) supplied in the package alongside the core distributed computing tools, all go to support that second objective - but I don't regard them as "the core of the problem". They are more akin to the froth on the cappuccino - decorative, and a good marketing device, but hardly fundamental to the coffee underneath. Like Erik (zombie67), I've seen a succession of lonely project administrators wrestling with message-board arguments about both the level and consistency of credits. But I also see a succession of equally lonely (and frustrated) administrators faced with issues like the -177 Maximum Elapsed Time Exceeded error (and, quite separately, losing work to the upload certificate change). If there is any "core of the problem" to be addressed, I'd prefer it to be the issues that arise from the runtime estimation elements of CreditNew, especially in the early days of new projects, new applications, and new host attachments: once the "long-term averages" that David mentions have been established, things seem to run smoothly, but not every research scientist or administrator wants (or will have the patience) to reach that state. _______________________________________________ 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.
