That's true. The discussion should not drown in talk about credit. As you point out, credit just happens to be one very visible indicator that the estimates are sometimes way off.
-- Janus On 2011-11-08 16:08, Richard Haselgrove wrote: >> > 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.
