Hi !

I'm currently only crunching for Einstein@Home, so I don't know how the participants in other projects feel about the credits system.

In the E@H forums, users ask many questions about credits, and complain a lot. It seems to be widely recognized that the credits system :

** fails to capture the amount of work performed on a
   WU (runnig an optimized project app will earn a 
   user a fraction of the credits)
** grants significantly different credits according
   to the OS running on a system - many turn to Wine
   to run the Einstein/Albert app under Windows to 
   get "proper" credits.

It seems that the benchmark-based credits system has shown its limits.

The situation would probably improve, at least within a project, if the project app itself determined the value of the credit to claim for a WU.

Has the BOINC team spent any thoughts on these matters? Is a redesign of the credit system a possibility, or maybe already in progress ?

Regards.

-rg-

An optimised app should claim less credit than a normal app since your computer did less work to complete the task.

There is a hook in clients after 5.2.6 to allow operations counts instead of just using the benchmarks. This seems to work well for the cross platform problem in the SETI enhanced app which is currently the only app using it.

---

BOINC WIKI

BOINCing since 2002/12/8

An optimised app should claim less credit than a normal app since your computer did less work to complete the task.

There is a hook in clients after 5.2.6 to allow operations counts instead of just using the benchmarks. This seems to work well for the cross platform problem in the SETI enhanced app which is currently the only app using it.

Hi Keck Komputers !

Yes, counting operations would truly improve the situation. So, what you say implies that the idea must be sold to the E@H team ...

Otherwise, I have to remark that I can accept that "an optimized app will claim ...", and not that "an optimized app should claim ...". I decidedly think it should not :)

I think a useful measure would weight the "amount of work" that a WU requires (as estimated at WU build time) or actually did require for completion, not the time it took to complete. The problem is quantifying the "amount of work" - which a standard benchmark cannot satisfactorily do, as the complains on the E@H forums show.

And yes, an operations count qualifies as a useful measure, thanks for the information.

Regards.

-rg-

---

An optimised app should claim less credit than a normal app since your computer did less work to complete the task.

A strange definition of work is that. If I can build 10 houses in a month and another person can build only 5 did I less work in that month?

An optimized client should of course claim more credit than a normal app since it does more WU in the same time as the normal app. But the problem with the current system is that credit is not claimed on completed work but on timexbenchmark and that opens all possibilities of cheating (look at the Rosetta-computer-toplist).

---

But the problem with the current system is that credit is not claimed on completed work but on timexbenchmark and that opens all possibilities of cheating (look at the Rosetta-computer-toplist).

I would like to see something like a two-way-calibration. The server could tell the client to claim more/less plus the client would tell the server to grant more/less. So after some time the clients would claim a similar amount of credits for similar WUs and the projects would grant comparable credits for a given computational effort.

Norbert

---

An optimised app should claim less credit than a normal app since your computer did less work to complete the task.

A strange definition of work is that. If I can build 10 houses in a month and another person can build only 5 did I less work in that month?

An optimized client should of course claim more credit than a normal app since it does more WU in the same time as the normal app. But the problem with the current system is that credit is not claimed on completed work but on timexbenchmark and that opens all possibilities of cheating (look at the Rosetta-computer-toplist).

It should claim less per task but more overall since more tasks are done in a given period.

From your example if both are being paid hourly then they would both have the same monthly paycheck. The BOINC system actually is better than that since you would both be paid per house at a rate similar to a person that can build 7.5 houses in a month. You put less effort into each house but get more done in total.

---

BOINC WIKI

BOINCing since 2002/12/8