I agree entirely with Ethan, and my position on the whole 'optimised' boinc manager situation is that it isn't in breach of the rules, but I consider it poor sportsmanship.

I agree 100%.

With regard to the use of optimised clients as the adage goes "It's not cricket" (Just like the underarm bowl delivered by the Aussies against the Kiwis back Feb 1, 1981 - a day no Aussie can be proud of)

---

Where on Rosetta's homepage did it say to download a different client to receive more credits? Users who read the Associated Press article who had no idea of other projects. . they should be punished because they didn't research things they had never heard of?

Just like in the real world (especially in the investment world), you must research before you play. The more you know, the better you will do. Know the game in which you play, before you join. This is universal. Even a brief scan of the message boards would clue in a newbie.

How does an apples to apples comparison hurt anyone? If you did the work, you get the credit. . if you did the work faster than the other guy, you get more credit. I'm not sure how this hurts anyone.

I agree. So going forward, make it so (number one). Changing the rules backwards is wrong. Some people (had they known) would have never participated to begin with.

And worse of all, they have now lost out on accumulating credit on other projects. Rosetta@home is unable to make that right. The people will have been played by R@H, used and discarded like a spent condom. Nice.

I sincerely hope it doesn't work out that way, as I don't believe that is anyone's intention.

I agree with your idea's of not back dating credits. It is wrong, no reason to "fine" or remove credits from past crunching. Just move forward. If rules are changed then these should not be grandfatherd backwards. I love the 401K analogy. Why take away what was given freely in the past. That is distastfull and could hurt the science as there would be an exoudus from the project, and bad press for the project. I for one would not join a project if it had been known in the past to remove credits because of some new fangled credit granting system.
It has not been done with other projects, when SETI changed the way it granted credits - they did not remove credits that had been granted, neither has any other DC project. I feel it would prove destructive to the project.

---

Star Trek references aside :)

The governement makes you accountable for false claims on past returns. . why should people be given passes on clients that granted more credits than the standard one? Because they were the first to use it they should be given amnesty? What do they have against a level scoring system? If they are number one in the current credit system, they should still be number one when the actual work is calculated. . right?

-E

Ethan, these are not false claims, in this case these claims are allowed under the current credit system. The IRS could not go back and make current laws retroactive. Neither should Rosetta.
If caught cheating the credits have been adjusted, and removed and in some cases removed from the project. And they have the right to do that, but to go back at this time and "adjust" the credits for everyone is simply bad managment.

---

I think we should make the changes to the credit system and back date them if that is acceptable to all the other BOINC projects.

edit: I deleted my original post because it was in response to someone who doesn't want to get it and I needed to fill the space.

How is this change going to be reconciled with all the other projects? I thought Berkeley were working on that.

I agree with mmciastro that the credit system in its current shape is not yet ready for deployment. :-( I get quite different granted credits/hour which will be a source of endless dispute and lead to cherrypicking of "credit-rich" WUs on Rosetta from those who aim for most credits. I wonder why the granted credits for different WU vary so much. How big is your sampling dekim? Perhaps there is too much inequality in the distribution of different WU on RALPH and too much uncertainty about the reported results that it does not work. It seems some WU were processed only by overclaiming clients while others were only processed by underclaiming clients. That needs to be corrected before rolling it out on Rosetta, either by restricting the estimation to trustable hosts or by ensuring the same host pool for each WU and the same factor each hosts contributes to the average credit/model. The more I think about it the more I think the easiest way would be to select different trustable hosts and use their values.

Why inventing a new credit system to level the playing field, which does not level it?

---

I don't have a problem with a credit scheme that grants 10 credits/hour for one WU and 5 for another, as long as over time they average out to cross project parity. After all, everyone would be getting a similar mix and that would be fair. Now, If it was known that "Xyz" WU got you more credits/hour than "Abc" Wus, then I can guarantee a small population of the community WILL abort the "Abc" WUs until they get a full cache of "Xyz" WUs.

I don't have a problem with a credit scheme that grants 10 credits/hour for one WU and 5 for another, as long as over time they average out to cross project parity. After all, everyone would be getting a similar mix and that would be fair. Now, If it was known that "Xyz" WU got you more credits/hour than "Abc" Wus, then I can guarantee a small population of the community WILL abort the "Abc" WUs until they get a full cache of "Xyz" WUs.

tralala & mmciastro, due to the random nature of the Rosetta algorithm each model takes a somewhat different time to complete, even for models of the same WU type. I think this is what causes the +/-30% or so variability in credits/hour that you are observing. Once you take averages of 10 crunched WUs or more you will get pretty stable average credits/hour values. In fact, looking at the numbers I have seen so far, Windows/standard client users should see about a 10% increase of their RAC or credits/hour, compared to the old system. Seems to be acceptable to me. Cherry-picking will not be possible because you will only know how many models you completed _after_ you crunched your WU.

---

I agree with your idea's of not back dating credits. It is wrong, no reason to "fine" or remove credits from past crunching.

How about rewarding people who have done more work than they have received credit for? That's "wrong" too?

The question is, do we punish the people who have done more work and received less credit (don't back-date) or do we punish the people who have claimed more credit than the amount of work they have done (back-date)? The right thing to do is back date it. There's no getting around it.

As I understand it, a fixed credit ratio shall be granted for completed decoys. And this ratio shall be determined from the type of work unit. If this is so, and it is nearing roll out time, then these ratios must have been already determined, or are being determined. If this is so, could those ratios be put in place here to allow us to experience the full flavor of the new system?

---

I think as long as overall it will average out to within a reasonable margin after running a few WUs then that's good enough for anyone. Do we need a reasonably large scale test of this or can the testing be done on Rosetta concurrent with the current system?

Cherry-picking will not be possible because you will only know how many models you completed _after_ you crunched your WU.

Cherry-picking will be possible unfortunatley, but it would take a bit of work to set up and I'm not going to say how ;) It will also be identifiable!

---

I can't sway myself from thinking that we have the opportunity to make the credit system fairly accurate based entirely on work done. I'm fairly sure everyone agrees credit should be based on work done. We have the opportunity to back date this to make the credit system consistent and fair throughout. If you've crunched more than me, you'll have more credit than me. If not, you won't. We know that's not the case at the moment, and I don't see how anyone can logically be against that.

Precisely, very well said.

Ditto, very well said!

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.

---

With what I've seen so far in one day with up to a 168% difference from lowest to highest credits for one single computer it's nowhere near ready to roll out on Rosetta.

You're moving to a cherry picking heaven at the moment I would guess.
Wouldn't be hard for some of the larger teams (or bord individual) to create a program grab the stats, see what the initial credits claimed are for that type and tell the team.
Could even build it into the boinc client and get it all done automatically.

---

Please show me results you are basing this on. With regards to cherry picking, we can easily prevent it if it becomes a problem, which I do not think it will.

---

With just 4 results returned I have a range between 12 and 19 credits/hour, which is a difference of 60%. As Fluffy has pointed out this WILL result in cherrypicking and it WILL result in constant complaining on the boards. It would average out if people weren't so mad at getting more credits than others. As fluffy also pointed out it is easy for teams and individuals to almost automate this.

I have one constructive and easy proposal though . ;-) Limit the number of WU sent to a specific host to one at a time with a one hour interval between sending work. This would result in a more even distribution of WU since no host can grab 20 WU of the same kind and inflate the average credit/model of such a WU with over- or underclaiming on all those results. I described it here how it is done and here is the BOINC user guide entry on that.

edit: "Good result" (get more of those WU) and "bad result" (abort those WU)

edit1: fluffy's results differ even more: Result 1, Result 2

---

these are very small numbers. it should even out. there will always be differences even with the same work unit because of the random nature of the runs.

---

I have one constructive and easy proposal though . ;-) Limit the number of WU sent to a specific host to one at a time with a one hour interval between sending work.

That would also limit people that don't give a rip about credits from loading a normal 2 or 3 day cache with work. Some (especially dial up users) only connect occaisionally, and if they can't get WUs during that time, they will be idle for the next 2 or 3 days.

---

these are very small numbers. it should even out. there will always be differences even with the same work unit because of the random nature of the runs.

You call 70% small numbers? That are definitely not small numbers! 10-20% I would call acceptable (not worth the cherry picking).

If you can easily prevent cherry picking why not do it?

---

I have one constructive and easy proposal though . ;-) Limit the number of WU sent to a specific host to one at a time with a one hour interval between sending work.

That would also limit people that don't give a rip about credits from loading a normal 2 or 3 day cache with work. Some (especially dial up users) only connect occaisionally, and if they can't get WUs during that time, they will be idle for the next 2 or 3 days.

This is intended for RALPH only where loading a cache is not senseful and doing other projects inbetween is recommended (especially Rosetta).

---

With what I've seen so far in one day with up to a 168% difference from lowest to highest credits for one single computer it's nowhere near ready to roll out on Rosetta.

You're moving to a cherry picking heaven at the moment I would guess.
Wouldn't be hard for some of the larger teams (or bord individual) to create a program grab the stats, see what the initial credits claimed are for that type and tell the team.

Fluffy, dcdc, tralala, I think you are mistaken: Cherry-picking is NOT possible !
The variability you are seeing in the credits is not between different WU types but because of the different completion times of the models _within_ the WUs. Even if, say, the first model of a WU takes a long time to complete this doesn't tell you anything about how long the following models will take. This is a completely random process. So terminating WUs that start with a 'slow' model won't help you either.

Fluffy, instead of 168% difference you could also say +/-45% difference with respect to the average. Example: average=10, 10-45%=5.5, 10+45%=14.5, 164% difference between lowest and highest. I think this is acceptable, considering that most values will be much closer to the average.

---

these are very small numbers. it should even out. there will always be differences even with the same work unit because of the random nature of the runs.

You call 70% small numbers? That are definitely not small numbers! 10-20% I would call acceptable (not worth the cherry picking).

If you can easily prevent cherry picking why not do it?

4 results - that is a small number.

---