I know this may sound simplistic, but, if everybody was running the optimized clients, along with optimized science apps (of course, optimized for every CPU and OS combo), there would be no way to "cheat by optimization", and the projects would get more work done. It's a win-win situation.

I'm sorry but here's a resounding 'NO'. This is a common misconception! At the moment optimized clients just affect benchmarks - they don't change how fast you process a WU - as the rosetta code is not yet open source.

So what that means is that at the moment, 1) some optimized clients geniunely try to even the playing field (ie. linux vs window), and 2) others return grossly inflated benchmark numbers (which can be considered involuntary cheating). Then, 3) there's an even more hardcore group of people who actually spend time modifying the stock or optimized clients with the sole purpose of cheating.

But, at the end of the day, they all return the same science. A WU is a WU, wether it grants the host 10 or 1000000 credits.

---

Team CFVault.com
http://www.cfvault.com

I know this may sound simplistic, but, if everybody was running the optimized clients, along with optimized science apps (of course, optimized for every CPU and OS combo), there would be no way to "cheat by optimization", and the projects would get more work done. It's a win-win situation.

I'm sorry but here's a resounding 'NO'. This is a common misconception! At the moment optimized clients just affect benchmarks - they don't change how fast you process a WU - as the rosetta code is not yet open source.

So what that means is that at the moment, 1) some optimized clients geniunely try to even the playing field (ie. linux vs window), and 2) others return grossly inflated benchmark numbers (which can be considered involuntary cheating). Then, 3) there's an even more hardcore group of people who actually spend time modifying the stock or optimized clients with the sole purpose of cheating.

But, at the end of the day, they all return the same science. A WU is a WU, wether it grants the host 10 or 1000000 credits.

This is all an argument for closing up the source to everything, period. And I agree, especially since once the science code is open it is subject to being messed with to the point where it returns erroneous results. Hence actually needing a quorum of three, which this project can live without since the code is not open.

---

[/quote]
This is all an argument for closing up the source to everything, period. And I agree, especially since once the science code is open it is subject to being messed with to the point where it returns erroneous results. Hence actually needing a quorum of three, which this project can live without since the code is not open.
[/quote]

I agree that keeping the science applications out of the public domain is good, I'm not so sure it makes that much difference with the manager.

While I agree cheating takes the fun away... Let's not lose sight of what is best for the project.

Setting a quorum of 3 results just for the sake of sorting out credits makes no sense when it's not neeed for the science. The project would need 3 times as many CPUs working for them to get the same amount of work done. Compare that to the impact to the project of even 25% of hosts being withdrawn because of the inequalities in the credit system. Which is better for the project?

Also, I (and probably others) were attracted to Rosetta partly because there is no waiting for credits. You finish your work unit, you get the credit (in most cases).

With a quorum it can take weeks, even months, before you get your credit and sometimes (as has happened with something like 80 to 100 work units I crunched for Predictor) you get no credit at all because the work unit got too many results or database problems on the project.

---

*** Join BOINC@Australia today ***

While I agree cheating takes the fun away... Let's not lose sight of what is best for the project.

Setting a quorum of 3 results just for the sake of sorting out credits makes no sense when it's not neeed for the science. The project would need 3 times as many CPUs working for them to get the same amount of work done. Compare that to the impact to the project of even 25% of hosts being withdrawn because of the inequalities in the credit system. Which is better for the project?

Also, I (and probably others) were attracted to Rosetta partly because there is no waiting for credits. You finish your work unit, you get the credit (in most cases).

With a quorum it can take weeks, even months, before you get your credit and sometimes (as has happened with something like 80 to 100 work units I crunched for Predictor) you get no credit at all because the work unit got too many results or database problems on the project.

You are right, I wanna see only positive results :-) The amount of Workunits to calculate is inconceivable :o

---

To me there's not enough optimized clients! There should be Rosetta clients optimized for every kind of cpu and OS out there and also a default unoptimized client for those who don't know what kind of cpu they have (sse,sse2,sse3 etc etc) To me, the thing that matters the most is getting the maximum amout of valid units crunched for the project. Now all these optimized clients should be made official by the project and only those should be used. This would eliminate almost any kind of cheating, no need for a quorum of 3 and would get more units crunched because almost everybody would be using specifically optimized clients.

---

@ sir-lion : myself for one i run normaly 2-5 projects on each computer i have therefore useing a client that is optimised for any one project would mess up the scores (eithor + or -) on the other projects

with the Boinc client i see changes happening it looks to me almost daily basis to the client so that would also require more updates to the optimised clients also wouldnt it

yes i do like the fact that we get almost instant credit for work done here and i also like the no redundancy. oh if there is any problem with a work unit or such im sure they would run it again (or run it inhouse) im sure they do this with any result that looks real good also

---

To me there's not enough optimized clients!(...) To me, the thing that matters the most is getting the maximum amout of valid units crunched for the project.

... then if that's the case, don't use optimized clients, because they do not affect the amount of work being done in any way whatsover. Optimized clients are optimized boinc clients, which mean higher benchmark, meaning higher scores - that's it. They have nothing to do with the Rosetta application, which itself is closed source.

Originally the optimized clients were brought up because of a nasty, still unresolved discrepancy in terms of benchmarks (and therefore credit) between win32 and *nix clients. Having an optimized linux version meant that the linux users would get the same ammount of credit for any given work unit than a win32 user would. Which is the way things should be, really.

Unfortunately, it also means that someone who compiles his/her own client can not only make the benchmark 'fair', he/she can just give an arbitrary number for the same benchmark. On other project, that's a problem easily resolved by the quorum. Say 5 hosts bring back with the same WU, and the calculated credit is 20, 25, 15, 520000, 22 - it's easy to spot the odd one out and nullify that fake result.

However in Rosetta, there's no quorum. So there's nothing to stop the scenario above, leading to this thread, the thread about redundancy and the now-defunct 'cheating thread' (which I'd rather not think about :-D)

Finally, as others have pointed out, it's also possible to change the benchmark numbers without having to use any of the complicated methods described around those forums. So, as you can see, this really has nothing to do with optimized or unoptimized clients.

The ones in favour of the quorum argue it will stop cheating and maybe even be positive for the science, given that we have a lot of resources available, when the ones agains argue it's a complete waste of perfectly good CPU usage, as it effectly slashes the productivity of the grid by 2 thirds.

---

Team CFVault.com
http://www.cfvault.com

Sorry but I'm going to have to agree with the users who want to stay with 1 result needed for credit to be given. As long as the results coming in are correct and valid, I see no big advantage in going upto 3. All I see (as many others have stated) is a huge project performance drop, and I also see a waste of resources.

Think about ClimatePrediction - they only send the model to one computer, unless the computer crunching the model takes a long time to send a trickle back (or errors out), otherwise it'll send it out to another. I don't think they have ran into one single invalid model (or from what I've seen that is, could be wrong).

---

"In the beginning the universe was created. This made a lot of people very angry and is widely considered as a bad move." - The Hitchhiker's Guide to the Galaxy

Think about ClimatePrediction

They don't use the benchmark*time credit system.

---

They don't use the benchmark*time credit system.

I do know, I was a beta tester for them. I wasn't refering to that, I was refering to how they send out work.

---

"In the beginning the universe was created. This made a lot of people very angry and is widely considered as a bad move." - The Hitchhiker's Guide to the Galaxy

They don't use the benchmark*time credit system.

I do know, I was a beta tester for them. I wasn't refering to that, I was refering to how they send out work.

Yes... the same way Rosetta does. The problem is that Rosetta DOES use the benchmark*time credit system. Going to a quorum of 3 is _one_ way to solve the credit problem. The other way is to use something other than benchmark*time. CPDN has fixed-length WUs and can have fixed amounts of credits. Rosetta has wildly varying lengths of WUs, so cannot do that. Flops-counting is an option.

Quorum of 3 = cut CPU power to 1/3. Increase load on server slightly. No client-side code changes needed. Server side needs basic validator, otherwise just "flip a switch". Can be turned back off at any time.

Flops-counting = cut CPU power by a small amount (1%? 10%?). Minor server-side changes. Fairly major changes to science application, so requires developer time and effort.

I would want to know more info, that only the project staff can get to (pretty simple SQL stuff), before I could decide what if anything is necessary. Without this info, all is speculation and opinion.

a) What is the "average credit" for all WUs issued over a given range of dates?
b) By host, figure the average credit for that host over the same range of dates and the number of WUs done. You would have to discard any hosts that didn't participate over the whole range, or that returned only a small number of WUs compared to the average.
c) Sort this list in various ways to come up with a real NUMBER of hosts that are "suspect" as possibly being "cheating" on credits. If that number is in the single-digits, and their reported benchmarks do not match their CPU type, then get rid of those participants. Repeat process every month or two, and don't worry about quorums, etc. If that number is relatively large, implement a quorum of 3 immediately as a temporary measure, and start work on flops-counting.
d) communicate what you're doing to the participants so we don't get blindsided. (Put in because of experience on other projects... Rosetta staff is good at this part.)

---

I don't know how the statistics db is set up. . but what about defining a maximum RAC per cpu? If you cap the number of credets a given machine is allowed to gain in a day (by cpu, yes hyperthreading throws this off, nothing is perfect), then people could 'enhance' their numbers all they want and it wouldn't put them at a big advantage over standard clients.

Maybe 300-350 per cpu/day? It could be done on the back end. . let boinc do its thing, then have a process that runs nightly that will adjust a hosts credits if over the threshold.

---

Maybe 300-350 per cpu/day?

I think there is just too large a range of "legal" amounts per day for this to work. My RAC of 241 for my PC is with Rosetta getting 50%, so I assume I could manage close to 500 if I did "all Rosetta" - and this is a single-core AMD 3700, not anything fancy. Single-PC RACs of over 1000 are certainly possible. Meanwhile, a Mac Mini is only managing a RAC of 61 with a 40% setting (sigh - it's the app, not the processor...). If the "fix" was RAC-based, it would be simple to have the Mini be doing the cheating, and set it's RAC to equal the "high end CPUs".

---

I think there is just too large a range of "legal" amounts per day for this to work.

Agreed 100%, plus, one would just have to figure out the max allowed rac and reduce their cheating to the allowed 'cheating range'. Wouldn't work at all.

The stuff that Bill Michael proposes 3 posts above is pure gold. I would really like to see the admins implement something like what he proposes. As he said - this is all simple SQL stuff and would be well worth it IMHO.

---

Team CFVault.com
http://www.cfvault.com

Simple thing right now would just be for the admin to link to the most optimized version of BOINC. Right now I think it's this one...
http://www.guntec.de/Crunch3r/

If you're using optimized clients because you also optimize SETI or whatever other project, go for it. If you're a point freak, go for it. If you just want to "keep up with the Jones", go for it.

It doesn't have to be a big deal as long as the information on how to optimize is shared. If the extra points help someone stay intersted, great. Hopefully people won't be scared away from the project just because of points.

Keep up the good work admins.

---

Jeff's Computer Farm

link to the most optimized version of BOINC

The client you linked to does nothing for the Rosetta science - all it does it return abnormally high benchmarks. In fact it prides itself of that fact, and I quote their site: "I'm not aware of any BOINC versions with a higher score."

What's the point then for people to join teams and try to climb the stats ladder? How can we even have stats competitions if all it takes is one download (or even less) to suddently return thousands of credit a day?

---

Team CFVault.com
http://www.cfvault.com

I didn't make myself clear on my last post, when I said there should be more optimized clients I meant not just the Boinc app but Rosetta too... There should be optimized Rosetta for Every kind of OS and processors be it Intel, Amd, Mac, Sun or whatever... And these optimized apps should be made standard by Rosetta so everybody would have to use them, any other app used should be rejected. This way, we'd all be crunching much faster and the cheating would be kept to a minimum. This would help the project in every way, more consistant results and in the points awarded, less cheating and a lot more units being crunched.

---

I didn't make myself clear on my last post, when I said there should be more optimized clients I meant not just the Boinc app but Rosetta too...

Compared with the Rosetta app that was running when I first joined (4.75?) the current app is heavily optimised already. I can't remember exactly how long it took in the early days, but I think 10-12 hours on a fast Pentium was common.

That's not to say it can't be optimised further, just saying everything is relative :-)

---

*** Join BOINC@Australia today ***

The problem is not Rosetta's only. The problem is the BOINC benchmarking system.

Optimized project apps and optimized BOINC clients are two seperate things. If you optimize the science app it claims less credit even though you are doing the same work, just faster, thereby penalizing the users of optimized apps who are doing more work. It is compensated by using an optimized client. Problem: There are many different projects with many different optimized project apps. (some official, some third party) Optimization of BOINC clients can be abused at worse, and at best still is not totally fair because they are not calibrated to the optimized science app.

It is a challenge. Only thing I am sure of is that if redundancy doesn't add to the science it should not be used as a feable and ineffective method to equalize credits.

I think all of the projects are aware of the issue, and the developers are looking at alternatives. The answers aren't easy because the projects are so diverse. Any solution must be reasonably consistent to all computers systems, all OS's and all projects. I tried to come up with ideas, but upon examination each idea was just as flawed as the current system. Somewhere, somebody always gets shortchanged.

As to optimized BOINC clients being cheating, that would be true only if they were only available to a limited few. They are available to everyone. Use if you want or don't. It is your choice, You are not being cheated. They are allowed, and in the case of users running optimized apps for some projects, optimized clients are the correct choice. They only create disparities if they are used on projects that don't have optimized science apps or that optimize science apps for only certain computers or OS.

---

Team MacNN - The best Macintosh team ever.