Credit / hour : not fair !
![[AF>HFR>RR] Black Hole Sun](https://einsteinathome.org/sites/default/files/imagefield_default_images/default-avatar.png?1347855344 "[AF>HFR>RR] Black Hole Sun"){kind=avatar}
19 Aug 2006 9:46:09 UTC
Topic 191705
(moderation:
Hi everybody
A determined number of credit is granted to each wu. The faster you compute them, the faster you get those credits. That's fair.
Every Boinc project is asked to grant the same credit per hour in order to be fair : I am OK with this.
Some projects invest time and efforts in optimizing the code of their client in order to make it faster.
The result is a pure benefit for the project : participants crunch more work in the same amount of time (projects goals are reached sooner, money is saved). I am also OK with this.
BUT, the efforts spent by the project team grants only part of the benefits of these efforts. Yes, the project will raise its computation power, reach its goals sooner and therefore save money, BUT it will not gain anything else. It will not gain new participants who always search for the best possible rac (those competitors that always upgrade their machines to crunch more than their teammates).
IMHO, projects who invest time and efforts in optimizing their clients should be allowed to benefit from a raise of computation power (over their existing participants), but also on the credit/hour part to gain new participants.
In the present case of 4.02/4.24 switch, the credit/hour of E@H should benefit form the 33% increase resulting from the optimized client.
This could motivate other Boinc project to make the same efforts. Every Boinc project could gain a lot by doing this : a lot of additional computation power, more participants, save money etc...
The problem might be that every project does not have enought money to dedicate specific efforts in optimizing their client as they mainly concentrate on the scientific aspect. In that case, there is a solution : ask for contributors like Crunch3r and Aksof. These guys can drastically help projects as they already prove. May be not by releasing their own optimized clients (possible problems with accuracy, credit correction systems....), but by helping the dev team (as for the current E@H 4.24).
Final words : The projects benefit from code optimization. The more we compute in a minimum amount the time, the faster the project reaches its goal (and saves money).
We are participating to help science. One of the counterpart is a competition based on credits, rac ... between users (do I have to remind that every project has top participant / host / team pages ?).
The Boinc plateform dev team should also take care of participants. Yes I crunch for science, yes I attach to projects that do interest me. By crunching, I also compete with other, and this last point should also be taken in account.
Credit / hour : not fair !
)
Even though you make valid points, I have to disagree with this. I think credit should be based entirely on the time taken. ie. the same host should claim about the same credit per hour whether the app is optimised to the max for the CPU, or if it is very inefficient. That way projects get more participation based on their merits, not because a participant will get more credit at one project than at other projects.
BOINC WIKI
BOINCing since 2002/12/8
RE: Even though you make
)
Well, we disagree on this point :)
Every project has a tremendous interest in optimizing its code since it reduces the amount of time needed to achieve its goals. We know that some projects do have fund rising problems : optimizing their code saves money.
Concerning the participation based on their merits, it is already the case for the vast majority of us. But, as you can notice on every project, the competition between participants as been taken in account since the launch of the Boinc plateform (stats pages). The point is projects should also care of their participants since we are the ones who participate. The project has its motivations, we have ours (interest in the project goal, credit, reliability of the servers....). Since we are the computing force, project should also care about what motivates us.
If Bruce reads this thread, I would be VERY interested in his opinion since he has to deal with all these elements.
I'm confused I
)
I'm confused I guess...........seems as the last few threads are crisscrossing their views.........
if one is OK with an attempt at every project granting the same credit/hour........which IS good......equal credit for the entire system just makes sense......
then it is common sense as well that if a project takes the time to work on speeding up their app......then they MUST decrease granted credit in order to maintain the system wide goal of unified credit per hour......otherwise the project won't hold to the system wide goal of unified credit/hour.
of course some won't like it, but that's the nature of the game........
your point about Einstein loosing some of the crunching power based on those hunting RAC is a good one.......but the reason they can do that is because the above goal of unified credit/hour has yet to be fully realized......it doesn't make sense to go against a goal the system is striving for to compensate for those not fullfilling the goal..........(that's the confusing part I hear people asking us to do)
dropping credit granted with a faster app makes sense if we're trying to pave a new way.......yes the transition will have it's pitfalls......but it's worth it if state once the goal is achieved is better.
let's keep laying pavement.
it's just change anxiety........I see it every day, and every field, every situation I run across......
Personally, I think they have
)
Personally, I think they have gone too far with the latest correction, and the rate should be reset to what it was with 4.02. This was in the ballpark with what I was seeing on S4 before Akos' apps became available, and compared reasonably well with SAH.
I will say when 4.24 came out my rates went up a little so an adjustment was justified, but I don't think EAH should be lowering their rate. The newer/other projects should do what it takes to get their rates in line with EAH and SAH, since they're the defacto "gold standards".
Alinator
Allowing for equalized credit
)
Allowing for equalized credit across projects is allowing for all projects to be equal in everyone's eyes, and then the merit of the project itself is what gains the users. If someone is interested in space exploration, there are projects for that, protien folding, chemestry, etc. It doesn't matter what project you take, your credits per hour should rate out the same. Keeps those who compete via multiple projects on a level playing field, and does not make one project so dominant that everyone is going to flock to it, and other project suffer.
Common sense is the key. Keeping it simple, by having a equalized credit rating across the board. People want simple. I don't go find the best credits, I follow what I believe in. Others do not, unless they have a simple choice. It helps all projects to be even.
RE: Ok, looks like it's
)
No, it is not. Mocking those you disagree with, instead of paying the respect of straightforward exposition, especially when the difference is about values, is a poor use of these boards. Einstein was blessedly nearly free of this tone until fairly recently. Please don't import the style of disputation that caused such harm to the SETI forums here.
Jim, I think you posted
)
Jim,
I think you posted your SETI answer in the Einstein forum!
All points still valid, but reverse 'them' and 'us' throughout....
[now there's a thought for an interesting world!]
RE: RE: Ok, looks like
)
Sorry, I have multiple tabs open and I actually thought I WAS in the SETI NC forum! (I have reinstalled my programs and haven't gotten around to changing the highlight on the tabs yet.)
I (as you might can tell) am also on the SETI forums, botu standard and Beta. This issue has been hashed out over and over there to the point where as you can probably tell, the regulars of us are quite fed up with it. That is the reason for my sarcasm at the first of my post, and I apologize sincerely for my mistake.
But now back to the question, yes, I run Einstein too, and the equalization in credits per project were fairly close using the original app, but I also have noticed the big jump in credits per hour since the optimized application came out.
/edit/ I was just about to quickly jump back in and correct this when I looked at my info on the left and said to myself "they still haven't got my beta tester tag fixed yet", then I looked at the top and it said "Cruncher's Corner"!
When asked a question and you are not sure of the right answer, I've found that the best answer is always "I don't know for sure, but I'll find out!"
RE: Allowing for equalized
)
Agreed, and between the EAH and SAH Dev teams over the last 6 to 8 months they have come to a reasonable compromise standard for scoring issues.
At this point it's the responsibility of the other projects to bring their scoring in line with them, rather than EAH and SAH continuously deflating the "value" of their work to match low scoring projects.
Of course this doesn't address the issue of what to do if a project starts "High Balling" to attract the credit whores. :-)
Alinator
QMC are looking at moving to
)
QMC are looking at moving to serverside credits and making the credit/hour rate equivalent to Einstein.
Rosetta is also in the throes of revamping its credit system, and one of its aims (although a minor one) is cross project parity.