For most of the people it would be fair to send out 3 WUs and take the middle. Many users now are using an optimized Boinc client to get more credits than other. So pls change the actually situation to a quorum of 3 results to stop cheating.

---

See this thread: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=349

---

Hmm so much to read but no reaction yet from the admin to do anything differently :(

---

I'm 300% for redundancy, especially after this thread.

---

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

For most of the people it would be fair to send out 3 WUs and take the middle. Many users now are using an optimized Boinc client to get more credits than other. So pls change the actually situation to a quorum of 3 results to stop cheating.

I do not agree that using an optimized core client is cheating. Let me explain.

I have two machines at home running boinc. One is an old slow Windows box with a 300MHz PII. The other is my Linux server with an AMD XP2600+. Obviously it will take the Windows machine a lot longer time to crunch a given workunit than the Linux box. However, all other things being equal, the amount of credit each gets for a given workunit should be the same. Using the stock core clients it is not. In fact, a windows box will claim about twice the amount of credit a Linux box will. That is because the windows client is already optimized whereas the Linux client is not. I've compiled my own core clients for my Linux box since the early 4.X versions of the core client. Now, both boxes claim about the same credit for a given workunit.

Cheating? No. Just evening the playing field. Maybe we should request that the Windows client be deoptimized (is that a word) so that it is on an equal footing with the Linux client.

Charlie

---

-Charlie

Actually for the project it's of no importance at all if people claim and get more or less credit. If they use a quorum of 3 they will just get 3 times less work done. So why would they do it? It's a problem of Boinc, not of this project. Rosetta shouldn't change a thing as far as I am concerned, as long as they receive valid scientific results. As for the optimized clients. Just ban them all together if it's that important. Or let everyone use them. Maybe that's a bit a simplistic view, but I think projects should not create unnecessary and duplicate work because of this 'credit' game. After all, it's no more than that, a game.

---

BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair

Let me play devil's advocate for a minute. .

There are around 9,000 users and 27,000 computers running R@H. Turning on triple redundancy would reduce this to the equivalent of 3,000/9,000.

What is in the best interest of the science project? I don't know the numbers, but I'd guess the number of people running the optimized client is limited to 5 or 10 percent of users/computers. . maybe 200/5,000.

Which is the lesser of two evils? 'Losing' 18,000 computers by turning on redundancy, or losing a much smaller percentage to people leaving from how they feel about the scoring system?

David Baker has stated in another thread that they are still CPU limited, probably by a factor of 10 or more. Triple redundancy only increases this to a 30-fold increase needed. . it's a lot easier to gather 90,000 people than 270,000.

I don't think I'd like knowing the work my 200 machines are doing will be cut by two thirds just to fix a problem that may be easier to resolve via other methods. . especially when those concerned can download and install the client themselves.

Anyway. . just throwing out another side of this. And just to make it clear, these are my opinions and probably differ from those running the project.

-Ethan

---

I think Rebirther was referring to the people with computers benchmarking at 6000 when every single other cpu of the same type benchmark at 1500 or so. That sort of 'optimization'. There are a lot of those out there, see my thread linked above.

---

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

I'm of HaFS's opinion. I personally don't really care if somebody gets more credit than I do for a workunit, as long as he/she computes the WU in a regular way and the result isn't fake or unusable.

I guess it boils down to the difference between people who do DC for the stats, the science or the fun. Don't get me wrong, I like stats as well. I do a daily stats posting on the progress of TeAm Anandtech on the TA forums for my fellow crunchers. But do I value stats before science? Nope.

I think that turning on redundancy would be one of the biggest mistakes R@H could do, especially in such an early phase with relatively few participants. The image that comes to my mind is a speedlimit of 50 mph or km/h because then those cars with a turbo or NOS won't have an advantage anymore.

If there's a way to fix the faulty benchmarking exploit, I'm all for a fix for that. But not the redundancy unless there's a strictly scientific reason aind gain.

In theory, by turning on redundancy, is there anything to be won besides the leveling of the score? I mean, won't a WU produce the same results over and over again even if crunched on another computer - assuming it doesn't error or there's a bad overclock or anything similar?

---

I think Rebirther was referring to the people with computers benchmarking at 6000 when every single other cpu of the same type benchmark at 1500 or so. That sort of 'optimization'. There are a lot of those out there, see my thread linked above.

Oh, those optimizations! Too bad we don't have a way to exclude them.

Charlie

---

-Charlie

I'm known as a little simple minded but I want ask something:
Why is the standard Boinc Linux client so low in benchmark?
I have 10 Linux clients (Sempron 2800+)running under LTSP that have a rating of 850-900. The same client running W2K is scored 1500. Simply recompiling the client without AMD optimized gives a rating of 1550. Optimized is 1700.

So it should be possible to take an average benchmark for all processors and then cut the rating (maybe +10% for overclockers).



(BTW Christian, seems time to rethink Your signature... ;-)) )

---

Teddies....

[OFFTOPIC]

BTW Christian, seems time to rethink Your signature... ;-))

I know man, I know. Have been watching you rise for over two weeks now. All I have is 5 PCs right here at home. No way to keep up with you :-(

[/OFFTOPIC]

---

Well, the topic of the thread is badly named, IMO. It's not about quorum but the damn, credit. I though the quorum was to make results more accurate (e.g. validity) not the empty crdit numbers.

Things would have been much easier if we had fixed credit per WU (like CPDN has) but it doesn't apply on WUs that need different time-to-complete.
I agree that the problem if of BOINC and not of any particular BOINC project.

I also wish a source code being available making the crunching faster hence science progress faster.

Damn, the credit hunters - as alfa/beta testers on CPDN, we were crunching without any credit award, with many crashes after houndreds of CPU hours processing untested models and happy to pioneer some new state-of-art models.
I mean - science first!

---

I think Rebirther was referring to the people with computers benchmarking at 6000 when every single other cpu of the same type benchmark at 1500 or so. That sort of 'optimization'. There are a lot of those out there, see my thread linked above.

I agree with Stephan and Rebirther.....there must be a better way of eliminating or restraining the more obvious credit deviants without impacting the science. It's very easy to say that the scoring is not important and the science is paramount.....it's a motherhood statement that few would disagree with. IMHO, it is obvious that great care was taken to include a scoring system in BOINC because it was considered an important motivator. However, it needs to maintain its credibility to be meaningful.....otherwise scrap it and save the cycles. (There would be consequences of course.....Rog:(

---

Hmm so much to read but no reaction yet from the admin to do anything differently :(

There is plent of info from Admin on the linx that Andrew provided further up explains alot on the processes they will be taking up

---

Join us in Chat (see the forum) Click the Sig


Join UBT

Damn, the credit hunters - as alfa/beta testers on CPDN, we were crunching without any credit award, with many crashes after houndreds of CPU hours processing untested models and happy to pioneer some new state-of-art models.
I mean - science first!

So, if I'm a credit hunter my cycles are less worth? :-))
I was betatester at TSC (without credit) and at FAD. One reason to leave TSC was cheating....

But I need the stats and the competition to keep me going with all puters in the long run.

---

Teddies....

unfortunatly we run into the same problem out there

there are multiple type of opinions on this

1) (mine) as long as the results arnt damaged who cares about the score system
2) the people who want to be #1 in the stats no matter what loopholes they must do
3) the people who want to have the stats 100% reflect what people actualy deserve
4) the people who tweek the software to make sure they at least get the normal points
5) the people who tweek the software to get more points but wont risk damagein work units

im sure there are alot more out there

and darnit if i dont get to the top 100 or 200 or 500.. then i dont my computers are doing the work to get the work done.. yea i look at the stats and i do care about them but i definatly dont want higher redundancy to be what the Admins think is nessary to FIX the problem. some one will always cheat if there is a way thats life

---

1) (mine) as long as the results arnt damaged who cares about the score system
2) the people who want to be #1 in the stats no matter what loopholes they must do
3) the people who want to have the stats 100% reflect what people actualy deserve
4) the people who tweek the software to make sure they at least get the normal points
5) the people who tweek the software to get more points but wont risk damagein work units

Well put. Now whose opinion is more important? :-) (j/k)
But seriously, I understand the redundancy solution has some downsides, so couldn't there be a better approach to benchmarking instead? Couldn't boinc use some un-falsifiable benchmarks for example?

I think all above groups would be satisfied if the stats were fair and square - because 1) still wouldn't care, 2) would be forced to play 'nice' 3) would be very happy indeed 4) wouldn't need to anymore and 5) would have a lot of uncredited, 'broken' wus.

---

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.

The only problem, of course, is compiling all those optimized versions of things. Funny, though, the people who want them seem to have no problem getting/making them. They should be made available to all, have no drawbacks for running them (i.e. the optimized versions usually have no graphics support), and be supported by the projects. Otherwise, when new versions of the science apps come out, you end up still running your old optimized version, possibly creating erroneous results. [edit] This was seen repeatedly on the Seti Beta project, until the creator of the optimized version of the app himself asked everyone to stop for the good of the project. [/edit]

[edit] See this post -- http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=99
[/edit]

I don't run the optimized versions of anything because of that last caveat, and nobody else should either. Only when the project supports them should they be run. There. Go ahead and disagree.

---

But seriously, I understand the redundancy solution has some downsides, so couldn't there be a better approach to benchmarking instead? Couldn't boinc use some un-falsifiable benchmarks for example?

At the current time, since Boinc itself is open source, the benchmarks are only as valid as the honesty of the person running them. Even there it gets problematic. Compare these two systems:

1600/2200
732/1960

Other than the clock speed difference, they're pretty much identical, both are Dell 4700's. The one difference is the OS, and hence version of Boinc that's running.

OK, so the integer values scale about right with the CPU speed, but the float bench result on the Linux box is about half what it should be: 1.6 gflops at 3.2 GHz ought to be 1.5 gflops at 3.0 GHz, yet it's reporting half that.

Flop counting is probably the only realistic way to go, the trick is to convince the Rosetta folks that it's really that important. The infrastructure is in place in Boinc as far as I know, we just need to hook into it. That would do a great deal to resolve the cheating AND divergent bench problems.

---