I asked at Ralph if it would be possible to back-date the new system so the credit system was consistent, and so we can see how much work we've actually all done here. I asked because I didn't think it would take much effort, and I think David Kim thought it was reasonably straight forward to do too (I might be wrong though).

Zombie - I read the post you're refering to and I think David said he was planning on doing the above (you're not going mad!).

---

They said the new system, once approved and official, would be applied to all credits retroactively since February. No polling for consensus of the crunchers. Decision made.

I've been following the discussion at RALPH, and I don't recall anything of the sort. I think you need to wait for RALPH to be back up so you can look at what was actually said.

They said the new system, once approved and official, would be applied to all credits retroactively since February. No polling for consensus of the crunchers. Decision made.

I've been following the discussion at RALPH, and I don't recall anything of the sort. I think you need to wait for RALPH to be back up so you can look at what was actually said.

I believe it was said and will be done.
I also assume (but do not know) that it will not alter the 'boinc credit' system, but will just be what the creits where and added to the 'rosetta credit' system.

It's all quite a mess and to me not thought out fully. Having two credit systems with similar names is very confusing, they should have use Points or somthing instead. (it's bad enough that boinc uses credit and work done to mean the same thing but in different places, credit on the websites and work done in the boinc manager)

But it's all pointless and traditional credit is not altering and that's what will be used and what the stats site will use.

---

Team mauisun.org

I think backdating any changes to February would be an excellent idea.

You should get credit based on the work you do. You do twice as much work as me, you get twice as much credit. That's fair. That's what we should want.

Consider this. Rosetta uses FPU power. Not SSE2, not MMX, or 3DNow. Just straight up FPU power. Now interestingly, the Athlon XP and the Athlon 64, clock for clock, have the same FPU speed. The FPU unit is almost identical across both processors. Therefore, a 2.2 GHz, 512 KB L2 cache Barton core Athlon XP 3200 will produce for Rosetta almost exactly the same amount of work in any given time as a 2.2 GHz, 512 KB cache Newcastle/Winchester/Venice core Athlon 64 3500. But because of optimised clients and no quorum, they won't get the same credit.

I'm not saying it's cheating, because the admins never said that optimised clients shouldn't be used. But what it has done is grossly overinflate the credit that some people and some teams are getting. XS for instance have an RAC according to Rosetta's current system of over 500,000. There's no way they are truly contributing over 5 TeraFLOPS per day. I'm not condemning them either, I use 5.5.0 as well. But I would like a system where I don't have to overclaim to remain competitive, and I would like to see people fairly rewarded for what they do. And I do want to see it backdated to eradicate nearly a year's worth of unfair credit granting.

---

Biggles-I can understand and empathize with you on your reasoning but I strongly disagree on changing or backdating credits. Climate Prediction did this about 2 years ago and caused months of problems for the project. Many people left because of an issue of trust with the project. I don't think this is what they are after. Granted should mean just that, not we may in the future review the past and change it. The flaws in the crediting system were put in place by the project and not the crunchers. I and many others have no faith in a project that wishes to change the past. I stopped CPDN when they did this and will stop Rosetta and not look back if they do ...so I am voicing MY opinion now before they make a serious mistake. Lets all move forward not backward. Also I also don't see how stat sites can handle any dual credit reporting systems.

---

I think backdating any changes to February would be an excellent idea.

You should get credit based on the work you do. You do twice as much work as me, you get twice as much credit. That's fair. That's what we should want.

Consider this. Rosetta uses FPU power. Not SSE2, not MMX, or 3DNow. Just straight up FPU power. Now interestingly, the Athlon XP and the Athlon 64, clock for clock, have the same FPU speed. The FPU unit is almost identical across both processors. Therefore, a 2.2 GHz, 512 KB L2 cache Barton core Athlon XP 3200 will produce for Rosetta almost exactly the same amount of work in any given time as a 2.2 GHz, 512 KB cache Newcastle/Winchester/Venice core Athlon 64 3500. But because of optimised clients and no quorum, they won't get the same credit.

I'm not saying it's cheating, because the admins never said that optimised clients shouldn't be used. But what it has done is grossly overinflate the credit that some people and some teams are getting. XS for instance have an RAC according to Rosetta's current system of over 500,000. There's no way they are truly contributing over 5 TeraFLOPS per day. I'm not condemning them either, I use 5.5.0 as well. But I would like a system where I don't have to overclaim to remain competitive, and I would like to see people fairly rewarded for what they do. And I do want to see it backdated to eradicate nearly a year's worth of unfair credit granting.

Biggles:
Couple questions:
On what math do you base your statement that " There's no way they are truly contributing over 5 TeraFLOPS per day."
Please show me the numbers you used to make that claim.I know, you can't. There is no information to back that statement at all just your "feeling" that we couldn't be turning out that much. Now, are we? I don't honestly know. My best guess is that on the average day we have somewhere between 2000-3000 high end computers running 24/7 on rosetta.
We also would have liked to have had a situation where the credits claimed were based on work accomplished and not on that miserable benchmark within Boinc but thats what we were stuck with.
That is the way it was done and thats how it was done.
You say unrealistic, we say that the optimised files allowed a level plaing field between the different types of cpu's that are used.
Are the points granted higher than the stock client? Yes they are BUT the RELATIONSHIP between the points granted to the different types of systems WITH the optimised files being used became FAIR for the first time. That and only that is why we used them.
I didn't mean this as a flame to you. I can truly understand how you feel. I just felt compelled to make a few points in response.
Thanks for your time,
Movieman

---

Wow..

I go away on a trip to come back and find a new credit system and everything.

Since I just use standard clients on standard servers, it looks like the new credit system will grant more credit than the old one.

I was never really in this for the points, but I can see why everyone is up in arms.

I looked at a period in time on the 17th. The old system added up to be 3766.65 while the new system showed 4347.83.

Would I have freaked out if it would have been the other way around, most likely not.

I guess since I am usually not around much, but have the servers crunching, as long as no changes are done that would require manual intervention on the clients to get them to report, I am okay with it.

If I have to stop by the office and redo clients, I will most likely just take the clients off and be done with it. Maybe check back in a few months to see if everything has settled down.

---

You say unrealistic, we say that the optimised files allowed a level plaing field between the different types of cpu's that are used.

I think it's an issue that the benchmarks used to determine calculated credit aren't based on reality (not pointing fingers at anything other than the 5.5 client).

Here are dhrystone benchmarks for the two main cpu's from: http://tinyurl.com/ewmo7

Pentium 4 3678 5787
Athlon 64 2211 5798

The first number is the Mhz of the cpu, the 2nd number is its integer Million ops/sec.

Compare that to a 3200Mhz P4 CPU rated lower than 200th in the Rosetta top computer list using the optimized client:

Measured integer speed 11667.51 million ops/sec

So clients are able to claim more credit than their computers can physically compute. That is the big red flag, just as it would be if Rosetta returned results that showed 1 + 1 = 3.

---

I assume what you're getting at BennyRop, is that in testing, the median may be shifted by the makeup of computers as (for e.g.) a P4 may suffer on an FPU intensive decoy, while an Athlon will fly through it.

Id love to see the system figure out if a machine happens to be quicker at a certain algorithm (compare the boinc reported stats and the new, calculated ones based on time per decoy?) and try to push out ones that a specific computer can finish quicker.

---

I wish I were the author of the comments that will follow. I subscribe to what it is stated on them a 100%


*********************************************************
Thoughts on the credit system (long)

As it is now apparent to everybody who has been following the Rosetta@ home forum, it is quote clear that the benchmarking system is inaccurate. While a new credit system is in the works, and hopefully will be implemented soon, the issue of the previous credits may still needs to be resolved. So, please bear with me while I offer my humble opinion on the matter. If I am to borrow from the real world, allow me to make an analogy:

Say, I employ two employees A and B. Both are assigned to do the same kind of work. Each employee is paid according to the amount of work they perform. Assume that employee A is a bit faster/more efficient, etc... than employee B (or vice versa, doesn't really matter). At the end of the month each employee delivers his/her production sheet. Employee A has assembled 1000 widgets and employee B has assembled 700 widgets. Employee A is claiming 10,000 dollars at a rate of 10 dollars per widget, while employee B is claiming 5600 dollars at a rate of 8 dollars/widget. I pay each employee as claimed. Note: I know exactly how much each employee is claiming and also the base rate of his claim since it is all in front of me from day one (database records). Both employees happily keep producing based on their understanding of the payment system.

After a number of years, employee B discovers that I have been knowingly awarding employee A at a higher unit rate than him even though it is exactly the same kind and quality of work. The remedy to this is not to take money back from employee A (note: I can only do that if-and-only-if I can prove that employee A has errors in number of widgets declared in his production sheet and actually has not produced the claimed 1000 widgets). The only viable solution is to go back and compensate employee B for his work by adding 3 dollars for every widget he/she has produced in the past.

This concept of equal pay for equal work is pretty standard these days everywhere. And yes it applies here. Don't forget that the employee has exerted effort (time, computer hardware, electric bill,...). He/she has the right for equal compensation (credits).

Employee B has every right to complain for unfair treatment because the end widget product is the same. Each employee has all the right to use whatever skills or knowledge he/she has to enhance his capability and produce faster widgets per day (tweaked hardware/software, more ram,...) as long as it does not affect the quality of the end product (WU results). But this does not translate to higher unit price per widget (they are the same widgets).

Employee A is not at fault here either. He/she has acted in good faith. The employee submitted his/her invoices (credit claims) to the employer and in full view of all other employees from the very beginning. If the employer has deemed that this unit price is excessive, he could have elected not to honour the claim. And keep in mind that, this is not the same as falsifying the widget count.

It is illegal to reclaim compensation back from employee A because: by agreeing to pay him/her (award credits) on a regular basis against an openly spelled out invoice (credit claim), the employer has entered into an understanding with the employee that this is acceptable to him. The employee may have elected not to do this work had he/she been compensated differently from the beginning. The compensation cannot be reduced on past work since it has already benefited the employer.

It is not wise or fair to ignore the past irregularity either. Understandably, employee B may elect to leave the firm and go somewhere else, even if for same or lesser pay. It is important to learn from the past errors, fix them and move forward with everybody on board.

The employer is not at fault either. He/she has been allocating compensation openly and has provided public access to all employee records (something that rarely happen in real life). By not bringing it to the employer's attention early enough, and by the majority of the people continuing to provide work at the status quo it could be assumed that everything is Ok. Remember, the employer has too much on his plate. This small detail was understandably skimmed over in the middle of all the other important stuff. Once it became apparent, plans have been put in motion to solve this problem in the near future. He is now off the hook.

This brings to mind the status of competitive sports we see on our TVs. Professional sports teams pushing each other to the limit of what is perceived to be legal. The more the competition, the more they push each other. It is up to the referee/ruling body to clearly and precisly dictate where the boundaries actually are. As long as it is tolerated, and publicly practiced by many, then it is "play on" until the referee say otherwise. Sometimes, it gets too far and a new corrective set of rules/procedures need to be placed to govern this practice in the future. Which I think is exactly the situation we are in here now.

That is all, no more no less.

Anyway. Back to topic. So in my opinion, to solve the past credit problem once and for all, and once the new credit system is in place, may I suggest the following procedure:

For every old protein
For every procedure used on this protein (RelaxAll, IgnoreAll, whatever ...)
For every WU returned
calculate the Credit claimed Per Decoy generated (CPD)= Claimed Credit / Number of decoys
Next WU returned

sort CPD in a descending order
ignore the top 2% values
Take the highest CPD value after that as being fixed (CPDf)

For every WU returned
Calculate corrected credit = decoys * CPDf
Adjust the awarded credit in the data base to be the new calculated credit.
Next WU returned
Next procedure
Next Protein

Please note:

The reason to ignore the top 2% values (and no more, or will affect employee A) is simple. This clears out (takes care of) all the:
potential rare PC flukes
a unit run that was too lucky
user "edited" the actual CPU time
etc..
By applying the above procedure on each protein/procedure pair independently, we remove the effect of the protein properties (length, etc..) and procedure complexity from the equation.

The end result of this is the equivalent of a quorum of thousands of WUs of the same protein/procedure. No participant will lose credit, and the few questionable cases will be automatically adjusted in line downwards (thus saving the huge ongoing task of identification/verification/clarification). The total credit will end up being consistent with the actual work done (the widgets) while the unit price (dollar per widget) is fixed. Equality, and hopefully peace restored.

Also, the adjustment of past credits as outlined above will not affect the other projects, because the new credit system will be in line with the compensation from other projects so no mass migration would occur. I sincerely hope that Bakerlab would give this proposal some consideration, for the long time benefit of the project.

In the mean time, I hope that everybody calm down (majority have done so, but few are still at it). I believe everyone had enough of the self righteous, name calling, blame allocating, finger pointing (directly - or currently indirectly) posts. Let us focus on the future and try calmly and equitably to fix the past (if technically possible), for the sake of this project and what it stands for (assuming that we really care).

Thank you very much.
---------------------
Disclaimer: I have been running an optimised Boinc client and continue to do so.
The opinions in this post are my own and do not reflect those of the XtremeSystems team.

Over on RALPH, they said very clearly that the stats since february would be converted, once we move to the new scoring system. Am I the only one who read it that way? Perhaps I misread it, but I don't think so.


I would show you the post, but RALPH is still down...

Okay, It's back up now. I did not misread it at all. Here is the quote from the moderator:

HERE IS THE CURRENT PLAN FOR ROSETTA@HOME

FIRST NOTE: The old system will still be in place and the exported stats will still be from the old system for now. We are just going to include new columns on the leader board lists for the new work based credits. This way people can compare the two, and there will finally be a ranking based on actual work.

For the work based columns, I will determine the actual work done from our archives which dates back to about February. Credit before February will be from the old system. So your total credit will include claimed credit before February plus your work based credit.

The hope is to eventually phase out the old system.

So yes, the plan *IS* to eventually have it so that your credit is the old method through fab, and everything since recalculated retroactively under the new system.

Somebody with authority needs to assure us that this is no longer the plan...and fast.

---

Reno, NV
Team: SETI.USA

No participant will lose credit,

Those that will keep the same credit = 1.
Those that will get less than the same credit (in this example) = the top 2%
Those that will get more credit = everyone else.

Given that there's at least a 2x difference between the lowest credit/model and the highest credit/model with the same boinc client (depending on the random number they were given), the crunch3r client gives 2-3x the the normal client credit, and the trux client 5-6x the normal client credit - your plan can be simplified to:
Sort the trux client credit/models, and pick the machine that was crunching on the slowest set of models. Then give everyone up to 12 times the credit that the normal client would have given.

This is part of the reason why the suggestions for the new system based the credit/model on a sample size of more than 1.. so we had some averaging happening.

If everyone was running 24 hour WUs, then the results wouldn't be so varied. But the results will average out over time.

---

As I interprete the statement of the project team, the recalculation of credits back to February will only target the newly introduced <granted work credits>. The claimed (and therefore granted) credits for the column <granted credits> remain unchanged. Therefore the changes in the credit system have no impact to the "classical" credit stats in BOINCstats etc. at the moment.

---

Love, Michi

Hi,

for everybody reading this thread and not reading the others any more as they change by the minute or for whatever reason, just a link to this post which quotes Dr. Baker's post on the XS forum.

Literal quote from one sentence of Dr. Baker there:

(there will be no backdating)

So at least that matter is settled now by the main authority of this project.


Regards and happy crunching to all.

Literal quote from one sentence of Dr. Baker there:

(there will be no backdating)

So at least that matter is settled now by the main authority of this project.

Great news! ...at least until they change their minds again.

It's sad that other forums are getting plain, direct information about what's going on, while we get nothing but silence on Rosetta's own website.

---

Reno, NV
Team: SETI.USA

Biggles:
Couple questions:
On what math do you base your statement that " There's no way they are truly contributing over 5 TeraFLOPS per day."
Please show me the numbers you used to make that claim.I know, you can't. There is no information to back that statement at all just your "feeling" that we couldn't be turning out that much. Now, are we? I don't honestly know. My best guess is that on the average day we have somewhere between 2000-3000 high end computers running 24/7 on rosetta.
We also would have liked to have had a situation where the credits claimed were based on work accomplished and not on that miserable benchmark within Boinc but thats what we were stuck with.
That is the way it was done and thats how it was done.
You say unrealistic, we say that the optimised files allowed a level plaing field between the different types of cpu's that are used.
Are the points granted higher than the stock client? Yes they are BUT the RELATIONSHIP between the points granted to the different types of systems WITH the optimised files being used became FAIR for the first time. That and only that is why we used them.
I didn't mean this as a flame to you. I can truly understand how you feel. I just felt compelled to make a few points in response.
Thanks for your time,
Movieman

I'll backtrack a bit and clarify.

When I said I don't believe XS are truly doing 5 TeraFLOPS per day what I really meant and what I should have said is that I don't believe XS are truly doing 500,000+ credits worth of work per day. Now 500,000 credits per day = 5 TeraFLOPS per day.

Reason I'm backtracking is that BOINC's idea of a TeraFLOP is rather far removed from reality. At perfect efficiency, 625 2GHz Athlons would be doing 5 TeraFLOPS. I believe XS are fielding more power than that, no matter what it's form. Thus I retract the TeraFLOP statement in proper terms.

With regards to not believing that XS are truly producing a sustained 500,000 credits per day, a glance at a selection of random computers in the XS team shows that the granted work credit (the new value which should be more accurate) and the granted credit values differ wildly. I've seen between 25 and 300% of the granted work credit being claimed. Does that make sense? I'm trying to remain easy to follow.

What that means is that I reckon somewhere between 1/3 and 1/2 of all XS's claimed credit is overclaim. Given the amount of power you truly have, I expect a true RAC, based on work done and not on the claimed credit given by optimised clients, to be somewhere in the region of 250,000. Simply because of the huge over-inflation given by optimised clients.

In different terms, if all of XS was to move to another project, say LHC for example, then the RAC of XS would drop dramatically.

Consider XS having a BOINC overall RAC of ~530,000 versus SETI.Germany having an RAC of ~500,000. They have 2037 users with credit this week, according to BOINCstat.com. XS in contrast have 178 users with credit this week, also according to BOINCstats.com. The numbers on Rosetta just do not stack up. In fairness, I'm not singling XS out here. I believe all the stats of anyone using optimised clients are wrong. I accept XS are doing three times as much work as the Dutch Power Cows etc. Proportionally on Rosetta, your stats are correct. Across BOINC, using credits, they're way out.

You say unrealistic, we say that the optimised files allowed a level plaing field between the different types of cpu's that are used.
Are the points granted higher than the stock client? Yes they are BUT the RELATIONSHIP between the points granted to the different types of systems WITH the optimised files being used became FAIR for the first time. That and only that is why we used them.

You're going to need to explain this to me a bit better. I understand that Linux systems need an optimised client to be credited fairly in comparison to Windows systems with the same hardware. I understand also that P4s generally need an optimised client to be credited fairly for the work they do in comparison to an AMD based system.

So why are dual Opterons running Windows running optimised clients? What do they need the playing field levelled for? All those systems are just getting way more credit than they deserve.

My ultimate reason for wanting to see credit changes backdated is that Rosetta is tearing apart the BOINC credit model. It wasn't perfect before, not by a long shot, but it was vaguely equivalent across projects. Rosetta awards far far more credit for the work done than any other project. I object to that.

---

I'll backtrack a bit and clarify.

When I said I don't believe XS are truly doing 5 TeraFLOPS per day what I really meant and what I should have said is that I don't believe XS are truly doing 500,000+ credits worth of work per day. Now 500,000 credits per day = 5 TeraFLOPS per day.

Reason I'm backtracking is that BOINC's idea of a TeraFLOP is rather far removed from reality. At perfect efficiency, 625 2GHz Athlons would be doing 5 TeraFLOPS. I believe XS are fielding more power than that, no matter what it's form. Thus I retract the TeraFLOP statement in proper terms.

With regards to not believing that XS are truly producing a sustained 500,000 credits per day, a glance at a selection of random computers in the XS team shows that the granted work credit (the new value which should be more accurate) and the granted credit values differ wildly. I've seen between 25 and 300% of the granted work credit being claimed. Does that make sense? I'm trying to remain easy to follow.

What that means is that I reckon somewhere between 1/3 and 1/2 of all XS's claimed credit is overclaim. Given the amount of power you truly have, I expect a true RAC, based on work done and not on the claimed credit given by optimised clients, to be somewhere in the region of 250,000. Simply because of the huge over-inflation given by optimised clients.

In different terms, if all of XS was to move to another project, say LHC for example, then the RAC of XS would drop dramatically.

Consider XS having a BOINC overall RAC of ~530,000 versus SETI.Germany having an RAC of ~500,000. They have 2037 users with credit this week, according to BOINCstat.com. XS in contrast have 178 users with credit this week, also according to BOINCstats.com. The numbers on Rosetta just do not stack up. In fairness, I'm not singling XS out here. I believe all the stats of anyone using optimised clients are wrong. I accept XS are doing three times as much work as the Dutch Power Cows etc. Proportionally on Rosetta, your stats are correct. Across BOINC, using credits, they're way out.

****

My ultimate reason for wanting to see credit changes backdated is that Rosetta is tearing apart the BOINC credit model. It wasn't perfect before, not by a long shot, but it was vaguely equivalent across projects. Rosetta awards far far more credit for the work done than any other project. I object to that.

How to say it politely:

Again it is the freakin BOINC uniformity mantra thing!!!!

Who cares about BOINC?

IT is the open source foolishness in BOINC that has opened the whole can of worms to start with. THEY, their open source, their ridiculous way of benchmarking, their allowing for easy ways of interfering with the benchamrks is the root source of all problems.

That and the freaking idea of the Boinc Purists that all projects must be run as if produced by a cookie cutter combined with their propensity of using the fighting word cheat.

Had the issue started here, I would have been in more forgiving mood .
But ,this is an old problem and has ben lived through in other projects and drat what a coincidence : the fights are allways started by the same people , arguing the BOINC Purist credo and spouting the same "the others are cheaters" argument. The last project was SETI. That can be veryfied

Do not compare member numbers , compare computers..one of our membres runs more than 150...all on Rosetta 24/7

As to LHC...bad choice of project.... That Freaking project is out of work.
For your information our team there has only 2 active members of a total of 3. Why dont get the administartor there to have new work available and maybe we can show there what a team of dedicated crunchers can do?

See in your obsession with optimized clients you forget the effect of overclocking and some Conroes, Kentfields and even power macs that were running 24/7 Rosetta. Rosetta @ Home was not a partime hobby for the XtremeSystems as it is for those Boinc Purists that Bash us. For our Rosetta Team it was a full time job. A job we were gladly to do.

It was that dedication that made many whinners dislike us. So they went to the old tricks and used the cheat word.

Bactrack all you want. That doesnt change the fact you are one of those that used the concept cheater very looslely. A look at your Rosetta Rac says it all.

Jose,
Face it dude ...Rosetta CHOSE to be part of the Boinc community and not run stand alone. Any project choosing to be part of Boinc should try to follow some sort of uniformity in credit allocation whether YOU like it or not. Your rants will not change that and YOU can't impose your will on the project or its members.

---

I'll backtrack a bit and clarify.

When I said I don't believe XS are truly doing 5 TeraFLOPS per day what I really meant and what I should have said is that I don't believe XS are truly doing 500,000+ credits worth of work per day. Now 500,000 credits per day = 5 TeraFLOPS per day.

Reason I'm backtracking is that BOINC's idea of a TeraFLOP is rather far removed from reality. At perfect efficiency, 625 2GHz Athlons would be doing 5 TeraFLOPS. I believe XS are fielding more power than that, no matter what it's form. Thus I retract the TeraFLOP statement in proper terms.

With regards to not believing that XS are truly producing a sustained 500,000 credits per day, a glance at a selection of random computers in the XS team shows that the granted work credit (the new value which should be more accurate) and the granted credit values differ wildly. I've seen between 25 and 300% of the granted work credit being claimed. Does that make sense? I'm trying to remain easy to follow.

What that means is that I reckon somewhere between 1/3 and 1/2 of all XS's claimed credit is overclaim. Given the amount of power you truly have, I expect a true RAC, based on work done and not on the claimed credit given by optimised clients, to be somewhere in the region of 250,000. Simply because of the huge over-inflation given by optimised clients.

In different terms, if all of XS was to move to another project, say LHC for example, then the RAC of XS would drop dramatically.

Consider XS having a BOINC overall RAC of ~530,000 versus SETI.Germany having an RAC of ~500,000. They have 2037 users with credit this week, according to BOINCstat.com. XS in contrast have 178 users with credit this week, also according to BOINCstats.com. The numbers on Rosetta just do not stack up. In fairness, I'm not singling XS out here. I believe all the stats of anyone using optimised clients are wrong. I accept XS are doing three times as much work as the Dutch Power Cows etc. Proportionally on Rosetta, your stats are correct. Across BOINC, using credits, they're way out.

****

My ultimate reason for wanting to see credit changes backdated is that Rosetta is tearing apart the BOINC credit model. It wasn't perfect before, not by a long shot, but it was vaguely equivalent across projects. Rosetta awards far far more credit for the work done than any other project. I object to that.

How to say it politely:

Again it is the freakin BOINC uniformity mantra thing!!!!

Who cares about BOINC?

IT is the open source foolishness in BOINC that has opened the whole can of worms to start with. THEY, their open source, their ridiculous way of benchmarking, their allowing for easy ways of interfering with the benchamrks is the root source of all problems.

That and the freaking idea of the Boinc Purists that all projects must be run as if produced by a cookie cutter combined with their propensity of using the fighting word cheat.

Had the issue started here, I would have been in more forgiving mood .
But ,this is an old problem and has ben lived through in other projects and drat what a coincidence : the fights are allways started by the same people , arguing the BOINC Purist credo and spouting the same "the others are cheaters" argument. The last project was SETI. That can be veryfied

Do not compare member numbers , compare computers..one of our membres runs more than 150...all on Rosetta 24/7

As to LHC...bad choice of project.... That Freaking project is out of work.
For your information our team there has only 2 active members of a total of 3. Why dont get the administartor there to have new work available and maybe we can show there what a team of dedicated crunchers can do?

See in your obsession with optimized clients you forget the effect of overclocking and some Conroes, Kentfields and even power macs that were running 24/7 Rosetta. Rosetta @ Home was not a partime hobby for the XtremeSystems as it is for those Boinc Purists that Bash us. For our Rosetta Team it was a full time job. A job we were gladly to do.

It was that dedication that made many whinners dislike us. So they went to the old tricks and used the cheat word.

Bactrack all you want. That doesnt change the fact you are one of those that used the concept cheater very looslely. A look at your Rosetta Rac says it all.

It was the intent of the BOINC developers from the beginning that credit could be compared across projects, hence the "BOINC mantra" about credits. It is still the intent of the BOINC developers that the credit be comparable across projects. Yes, the benchmarks were not perfect, but people should at least try to make the credits even across projects for a specific computer. The optimized clients were created to address a specific perceived problem with credits being under requested for a couple of reasons the main reason of which does not apply to Rosetta.

I am not going to backtrack. Widespread cheating on credits will harm the project as people who do not believe in cheating leave the project to the minority that are cheaters. In S@H classic some of the credits went so far as to cheat on the science as well (nothing like returning the same answer for all tasks), none of the credit problems here rise to quite that level.

My take is the fairest thing to do once the kinks are all worked out of the new credit granting method is to back date it as far as possible.

---

BOINC WIKI

Jose,
Face it dude ...Rosetta CHOSE to be part of the Boinc community and not run stand alone. Any project choosing to be part of Boinc should try to follow some sort of uniformity in credit allocation whether YOU like it or not. Your rants will not change that and YOU can't impose your will on the project or its members.

Man, get it into your thick skull. I am not trying to impose my will on anyone . I am just pointing to the obvious fact that those of you that worship at the BOINC altar do not seem to get:

1-The open source nature of BOINC makes it vulnerable to tampeering. So any issues of tampering have to be dealt at that level first. Secure the credit granting parameters, close the source.

2- The developers at Rosetta knew about and allowed the use optimized clients. So their use was not banned and thus it is legit. Tarring everyone that used as them as cheats is unfair and is not true.

3- The attempts to impose multiple Quorums at Rosetta (which was the first salvo of this battle) is not practical. It is a waste of computing ressources as the structures of the work units we are crunching are known and all waht we are doing is fine tunning the Rosetta software.

4- The issue is credits : BOINC Credits . Add to that that this fight happened in another forum..the same people started using the word cheat and everything degenerated from there. So when the "cheating "complainers started here, we knew what was comming: It was going to be the SETI revisited.

But why should I tell you that? By your credits it is obvious where your project loyalty/priorities lie and cerratinly they dont lie with Rosetta.