Credits

[yoyo]

A post by David Anderson regarding credits. Seems that I must grant less:

Code: Alles auswählen

I'd like to establish a policy to normalize credit,
i.e. to have BOINC statistics sites scale the credit
reported by those projects that are granting too much credit.
My proposal:

1) Use the system developed by James Drews:
http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php
as the source of data.
To compare two projects, he uses only the hosts that are attached
to both projects.  Projects that attract faster hosts are not penalized.

2) Use SETI@home as the reference project,
because it is largest (hence most overlap) and its credit policy
attempts to conform to the definition.

3) If a project has a ratio X > 1.5 relative to SETI@home,
its credits (both total and RAC) will be divided by X.
Everything displayed by stats sites should use this "scaled" credit.

Currently the projects that would be scaled are:

ReiselSieve (X = 4.365)
Cosmology@Home (X = 1.878)
yoyo@home (X = 1.510)

(PS3GRID is exempt because it does most computation outside the CPU)

Comments please.  It's very important that we address this problem.

-- David
_______________________________________________
boinc_stats mailing list
boinc_stats@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_stats
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[quote][/quote]

[Thommy3]

I am no fan of scaled BOINC credit, but most people are, so just do it.

[pschoefer]

A typical David Anderson solution... in many parts nothing but nonsense, since there are that many different systems and requirements of applications.

If more crunchers crunched evolution@home, which gives a bit less credit than OGR on many machines, yoyo@home would be granting less than 1.5 times the SETI@home credits on average...

And if SETI@home changes its credits the next time, every other project has to react?

[suguruhirahara]

A typical David Anderson solution... in many parts nothing but nonsense, since there are that many different systems and requirements of applications.

But the system of credits needn't be different between projects.

Actually I don't like projects which "seems" to encourage people crunch for them, by proposing much more credits than others. At first the aim of introducing fixed credits is to prevent socalled cheaters from getting higher credits than the other people, isn't it?

Gruß
suguruhirahara

[JohnMD]

Yoyo is so close to David Andersens limit that a small adjustment to OGR - down to the level of larger cosmology wu's - would do the trick.
Larger cosmology wu's earn a little more than smaller ones - which is only reasonable as they can't restart. I lose about 1 wu per week due to involuntary restarts - larger work units lose on average more time.

[pschoefer]

Yoyo is so close to David Andersens limit that a small adjustment to OGR - down to the level of larger cosmology wu's - would do the trick.
Larger cosmology wu's earn a little more than smaller ones - which is only reasonable as they can't restart. I lose about 1 wu per week due to involuntary restarts - larger work units lose on average more time.

If all yoyo@home participants who crunch SETI@home, too, installed the optimized apps, yoyo@home might fit into the limit, as well. This again shows the nonsense in David's new policy.

And it's funny that the limit is only in one direction... projects granting less credits than SETI@home can stay at their niveau. I wonder if David just wants to have SETI@home as the project with the highest credits?

[Baboeuf]

i didn´t crunched that much for yoyo but the two wus from muon lost much processor time (eg from 4 hours to 3:30) so i lost around 10thousands seconds! perhaps it would help if that is fixed and there is no loss of processor time anymore!? the credits per 'time' would be a "better" ratio than!

[Honza]

What David is proposing is reasonable.
Is there is something wrong with that? Perhaps the fact that BOINC itself wasn't able to deal with the issue automatically over the years.

This is a quick&dirty fix, not a solution.
It will become much more difficult when we have optimalized, x64, GPU, Cell etc. applications.

Anyway, I think it is a good move to prevent excesses so let's do it.

[yoyo]

There is a problem for me. Some PS3 crunchers are claiming, that I grant to less credits compared with PS3GRID. David claims that I give to much credit. But credit for ogr is given based on what was crunched, means the number of iterations. So the credits for PS3 are given based on the same rule as for Windows, Linux, Mac and Solaris.
yoyo

[Michael H.W. Weber]

i didn´t crunched that much for yoyo but the two wus from muon lost much processor time (eg from 4 hours to 3:30) so i lost around 10thousands seconds! perhaps it would help if that is fixed and there is no loss of processor time anymore!? the credits per 'time' would be a "better" ratio than!

Well, perhaps it would be better if you would just deactivate support for beta projects? You should know that issues will occur - that's why beta projects are just for those willing to risk credits. Main focus here is to iron out problems not to accumulate points.

Michael.

[Baboeuf]

Well, perhaps it would be better if you would just deactivate support for beta projects?

i just wanted to say that this could be one step to solve the problem with the credits. not more, not less!

[pschoefer]

Looks like everything will stay as it is. Since Riesel Sieve doesn't really overgrant that much, Mr Anderson doesn't see a reason to have the credits put below his S@h credits any more.