Report Cheating

you can report it here if you like. I don't know of any official method to do so. you could write to setidba@ssl.berkeley.edu, but I know they're swamped with mail since classic shut down.

If you give links to your proof, others would certainly make comment.
tony

at BOINC

you and others have to calculate, at least 3 Results

i think this is not so easy with at SetiClassic


if yo found somethink that we dont know

an e-mail at

<a href="mailto:ulrichbrinkschmidt@teleos-web.de"><img src="http://home.teleos-web.de/ubrinkschmidt/screen/email.gif"></a>

would help

so i can report this to David Anderson

edit E-Mail

ulrichbrinkschmidt@teleos-web.de

Greetings from Germany NRW
Ulli

Lets see some details of this alleged cheating before we all go off on one.
If Alaskan would care to share the information here then we can evaluste it.
The Developers will also get to hear of it if necessary.

____________

Hard to cheat with how they calculate credits given.

Number of results returned have to match a hard to duplicate class of checksum for EACH WU, and if they dont validate with OTHER returns, their ignored.

Submitting false claimed credit amounts wont help you much either. Each WU is sent to 4 people, and 3 results are required that validate before credits are given, and its not the high/low credit claims but the MIDDLE of those 3 returns that all 4 will get.

So you can see, cheating would probably require hacking the cottenpickin database.

There are a number of ways to influence the system (cheat), but, the ability to efffectively gain much from these exploits is fairly low. The first screen is that the work has to be downloaded and processed into a valid result. So, that eliminates the largest part of the prior exploits where work could be "cloned", cherry checked, or recycled. Since these were the primary ways that scores were inflated this is a pretty decent advance.

You can "cook" the books on benchmark scores to inflate claims, but, on most projects this matters not because the claim averaging of the quorum removes most of the influence of these. For CPDN it matters not at all because they use flat rate rewards, Prime Grid caps the claims, leaving only Rosetta@Home where this can still be pursued with some potential.

Again, the system is not perfect, but, it IS pretty good in limiting the effects of the most egregious attempts
____________

I agree...BOINC is open sourced, there are optimized clients for SETI and prolly other projects and you can have several computers analyzing WU's.Optimized MIGHT be considered cheating, and altering BOINC MIGHT be considered cheating, and using 20 computers MIGHT be considered cheating, but given that all those methods ARE allowed, how can we define cheating? I don't know that there really is a way to "cheat" or if it is at all possible...although with more info we MIGHT be able too tell............

I think we can assume the credit system is total baloney! I still process workunits (SETI and other projects as well) only because I think the science is important. I am offended, though, when I find computers claiming 3 to 6 times the credit for the same work. Just look at this:

Measured floating point speed 6292.45 million ops/sec
Measured integer speed 8453.17 million ops/sec

The above was reported from a BOINC client labeled 5.2.6 for a P4 2.8 and results in a claim 6 times what my computer has recently claimed for similar work. This kind of thing is just outrageous.

With all the hacked BOINC clients the client version numbers are meaningless. Any fool can produce a client that will claim any arbitrary amount of credit.

And, to argue that the quorum of results will even out the credits is naive. There are enough 'rogue' clients so that 3 or 4 will appear together in a quorum often enough to skew the credits granted toward the larger values for those machines. It's true that I will also sometimes benefit. But with Rosetta@Home that argument fails altogether. The machine for which I retrieved the speeds above is consistently granted these inflated credit claims for ALL the SETI workunits it does. So where is the 'It all evens out in the end'?

I have also recently seen what may be a new credit exploit. I have found a Pentium machine (or machines) that appears to be running at a 100% overclock - I mean the it must have a system clock that is 2 times the normal clock. I wouldn't have expected that an Intel chip could be overclocked that much. I suppose it's possible with exotic cooling solutions but it's very hard to believe. In addition it claims 4 times the credit for the very same workunit I've processed using the very same science app. It is more likely that this machine (or machines) is not what it says it is and may very well not even exist. I can only think that this machine (or machines) exist for the sole purpose of obtaining inflated credits.

I have been deliberately vague about the computers and numbers above because I don't want to point fingers. After all, I could be wrong or overreacting.

Anyway, I'm here for the science, not the credits. All these machines, while asking for more credits than (I think) they deserve, are actually producing useful science results (hope so anyway). But I'm still offended by the greed and sad but not surprised that such a thing exists.

Thanks for listening to my rant - I feel lots better now.

nice rant, I enjoyed reading it.
heck, I even agree with some of it, but I am only going to comment on this bit:

{snip}
I have also recently seen what may be a new credit exploit. I have found a Pentium machine (or machines) that appears to be running at a 100% overclock - I mean the it must have a system clock that is 2 times the normal clock. I wouldn't have expected that an Intel chip could be overclocked that much. I suppose it's possible with exotic cooling solutions but it's very hard to believe.
{snip}

With the current method and clients, if other idle processes are running at the same time, credit claims can be greatly inflated because of the longer measured run time. This happened if you ran BOINC/Seti and Seti Classic at the same time. The BOINC WU could take almost ten times longer to run and claim almost ten times the credit. But calling these high claims cheating is subject to debate, as it actually took that much time to do the result.

You might also get the same effect by running two or more copies of BOINC at the same time. The credit claimed by each instance of the client would be multiplied by the number of instances of the client running. This being done by any high credit returned account would look suspicious and would be easy to detect over time.

The only effective scheme for large scale cheating that would not be detected and filtered out to some degree would require either someone with a very large number of systems setting up separate accounts for them, or a large number of people working as a group with their different accounts. To be of any real cheating value, they would have to be organized into a Team and cheating for a Team, not an individual account.

By setting large cache sizes they could download large numbers of WU at about the same time. Then compare WU ID's across their base of systems. ...

Anyway, I'm here for the science, not the credits. All these machines, while asking for more credits than (I think) they deserve, are actually producing useful science results (hope so anyway). But I'm still offended by the greed and sad but not surprised that such a thing exists.

Thanks for listening to my rant - I feel lots better now.

The standard client is a plain vanilla generic one sizes fits all. Optimized clients are CPU/OS specific. Therefore they increase the benchmark results.

It is of course trivial to just edit the benchmark figuers in client_state.xml.
It only needs repeat editing every week after the regular benchmark.

What's more amazing than the possibility of cheating is this thread now has 18 replies, all generate by a single unsubstantiated throwaway comment, which the OP considered so important that he hasn't bothered to return. Sad.

____________

he send me an e-mail, thas he was wrong, he thought on Seti classic

...

Greetings from Germany NRW
Ulli

With the current method and clients, if other idle processes are running at the same time, credit claims can be greatly inflated because of the longer measured run time. This happened if you ran BOINC/Seti and Seti Classic at the same time. The BOINC WU could take almost ten times longer to run and claim almost ten times the credit. But calling these high claims cheating is subject to debate, as it actually took that much time to do the result.

You might also get the same effect by running two or more copies of BOINC at the same time. The credit claimed by each instance of the client would be multiplied by the number of instances of the client running. This being done by any high credit returned account would look suspicious and would be easy to detect over time.

Since BOINC uses cpu-time, while run-times can be 10x as long the reported cpu-times will only be slighly increased.

Only on win9x that doesn't know anything about cpu-time would this be an issue.

Please forgive me for complaining again and pardon me if I seem to be foaming at the mouth. This is another example of what I think is a blatant abuse of the credit system:

CPU type GenuineIntel
Intel(R) Pentium(R) M processor 1.86GHz
Number of CPUs 1
Operating System Linux
2.6.14-1.1644_FC4
Measured floating point speed 10712.22 million ops/sec
Measured integer speed 20244.38 million ops/sec

The above machine is using an optimized science app which I have no complaint with and it is using a non-standard client which may be the offender.

I have read: 'So what? The machine runs the WU's faster and gets less credit for each.' That statement is entirely false in this case. The above machine ran the exact same workunit as mine in a remarkably short time (less than mine and not a bad thing) and by the same measurement as mine claimed 5.3 times the credit. In addition, looking at other results returned by that machine shows that it is consistently granted credits near its claims. This reinforces my allegation that these 'rogue' machines are in fact skewing the granted credits (unfairly) upward more often than not.

What is the solution? I suggest that only approved clients be allowed and that there be some method of verifing that the returned results have not been tampered with.

And one last note: Oh my god! I'm turning into a cranky old man!

Please forgive me for complaining again and pardon me if I seem to be foaming at the mouth. This is another example of what I think is a blatant abuse of the credit system:

CPU type GenuineIntel
Intel(R) Pentium(R) M processor 1.86GHz
Number of CPUs 1
Operating System Linux
2.6.14-1.1644_FC4
Measured floating point speed 10712.22 million ops/sec
Measured integer speed 20244.38 million ops/sec

The above machine is using an optimized science app which I have no complaint with and it is using a non-standard client which may be the offender.

I have read: 'So what? The machine runs the WU's faster and gets less credit for each.' That statement is entirely false in this case. The above machine ran the exact same workunit as mine in a remarkably short time (less than mine and not a bad thing) and by the same measurement as mine claimed 5.3 times the credit. In addition, looking at other results returned by that machine shows that it is consistently granted credits near its claims. This reinforces my allegation that these 'rogue' machines are in fact skewing the granted credits (unfairly) upward more often than not.

What is the solution? I suggest that only approved clients be allowed and that there be some method of verifing that the returned results have not been tampered with.

And one last note: Oh my god! I'm turning into a cranky old man!

Please forgive me for complaining again and pardon me if I seem to be foaming at the mouth. This is another example of what I think is a blatant abuse of the credit system:

CPU type GenuineIntel
Intel(R) Pentium(R) M processor 1.86GHz
Number of CPUs 1
Operating System Linux
2.6.14-1.1644_FC4
Measured floating point speed 10712.22 million ops/sec
Measured integer speed 20244.38 million ops/sec

The above machine is using an optimized science app which I have no complaint with and it is using a non-standard client which may be the offender.

I have read: 'So what? The machine runs the WU's faster and gets less credit for each.' That statement is entirely false in this case. The above machine ran the exact same workunit as mine in a remarkably short time (less than mine and not a bad thing) and by the same measurement as mine claimed 5.3 times the credit. In addition, looking at other results returned by that machine shows that it is consistently granted credits near its claims. This reinforces my allegation that these 'rogue' machines are in fact skewing the granted credits (unfairly) upward more often than not.

What is the solution? I suggest that only approved clients be allowed and that there be some method of verifing that the returned results have not been tampered with.

And one last note: Oh my god! I'm turning into a cranky old man!

32.29 Andy,

that was based upon ONE users figures and is more speculation on ideals than on reality

____________

32.29 Andy,

that was based upon ONE users figures and is more speculation on ideals than on reality

Andy, did you see/read this OLD thread I bumped up for you?

old thread

Andy, did you see/read this OLD thread I bumped up for you?

old thread

CPU type GenuineIntel
Intel(R) Pentium(R) M processor 1.86GHz
Number of CPUs 1
Operating System Linux
2.6.14-1.1644_FC4
Measured floating point speed 10712.22 million ops/sec
Measured integer speed 20244.38 million ops/sec

CPU type GenuineIntel
Intel(R) Pentium(R) M processor 1.86GHz
Number of CPUs 1
Operating System Linux
2.6.14-1.1644_FC4
Measured floating point speed 10712.22 million ops/sec
Measured integer speed 20244.38 million ops/sec

looking at the benchmarks, this machine has clearly been tampered with.
shift the decimal point in the benchmarks one position to the left and you have realistic numbers for that CPU when using an optimized BOINC client under linux.

No, that's too rough a cut.

Back when I was crunching on a Pentium M 1.8GHz with an optimized client, I had around:
Measured floating point speed: 3500 million ops/sec
Measured integer speed: 5500 million ops/sec

So it looks more to be off by a factor 3 or 4, not a factor 10.

No, that's too rough a cut.

Back when I was crunching on a Pentium M 1.8GHz with an optimized client, I had around:
Measured floating point speed: 3500 million ops/sec
Measured integer speed: 5500 million ops/sec

So it looks more to be off by a factor 3 or 4, not a factor 10.

were you running windblowz or linux?

whoops, you're right, I missed the "M", so I was thinking of the scores of the regular 1.8

Some news about cheating in classic in the Tech News.

Regards
____________

Going to be about 900 upset old Classic users hehehehehehe
____________
And the beat goes on
Sonny and Cher

BOINC Wiki

Good grief!

9% of the top 10,000 Classic crunchers were cheaters? Almost 1 out of every 10 of them???

What a bunch of losers.

I wonder what the percentage for the top 1000, or the top 100, would be.

Regards Hans
____________

I wonder what the percentage for the top 1000, or the top 100, would be.

I Realize this isn't going to happen, but I'd like to see the "obvious", "unmistakable" cheaters named publicly. They'd deserve what they get.

Hi, I'd like to know how to report cheating?

Ok, OK I cheat, I use the optomized BOINC client so I claim an average of 12 credits rather than 6 per WU.

Dues not help as 95% of the time I claim the lowest of the 3 for granting credit.

But remember to visit and join Boinc Synergy, everyone likes Boinc Synergy.
____________


Pizza@Home Rays Place Rays place Forums

What is the solution? I suggest that only approved clients be allowed and that there be some method of verifing that the returned results have not been tampered with.

So what's the use of Open Source software when only "approved clients" are allowed?

Well, I think that instead of removing the work units from the cheaters they should just have divided them by 37.5 BOINC work credits and then multiplied everybody else's credit units by the same number and added them to the quotient of all average unit credits to come up with an adjust work credit unit average and by that ... OOPS!

(running thataway --------------------------------> quickly before people start throwing things)
____________
.

Do you have links to the work units you're concerned about?

Good grief!

9% of the top 10,000 Classic crunchers were cheaters? Almost 1 out of every 10 of them???

What a bunch of losers.

The first complaint.

Not sure about that. 517K hours and 90K results is roughly 5 hours per result, which is within the ball park of my historical average of 4.5 hours per ...
____________

I Realize this isn't going to happen, but I'd like to see the "obvious", "unmistakable" cheaters named publicly. They'd deserve what they get.

Are benchmarks like the ones reported by this computer possible? It seems kind of high for a 2.60GHz P4.

____________
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)

I don't know what happened to my stats. As of when the last snapshot was taken i had 7536 units completed. And as of of Dec 15 I had 12824 units completed,I had divided my 99 setihide caches into four groups and burned 3 groups each with a copy of the command line client and setihide onto cdrw and copied them onto my 3 old computers in order to clear out my cache more quickly , I went on holidays on the 20th leving four machines running seti. When I returned on the 29th my stats had some how jumped to 34799 work units which is impossible and none of the completed units got returned.

Today I checked to see if they updated and fixed this error and now it says I have 0 work units completed. what happened to my stats i did nothing to cheat

This actually sounds like you may have been bitten by a bug in SETIHide that was similar to the bug observed with SETIDriver right at the end. If so, the results that you don't think got returned actually did, and probably many times over.

Here's what happened - Berkeley started sending out a "this project is ending" message when a work unit was returned. Unfortunately, SETIDriver didn't know what that message meant. Since it didn't get a "received" or a "refused" response, it just assumed that the connection had failed and marked the result as "unsent".

Result - the *next* time a WU completed, SETIDriver attempted to send *both* the new result, and the previously "unsent" result, resulting in a duplicate submission - but it still couldn't tell that either were sent, and now there are two "leftovers"

Same thing next time - except that one "good" result and two "duplicates" are sent. Next time, it's one "good" and three "duplicates", then one and four, one and 5, 1/6, 1/7, 1/8, 1/9, 1/10, etc. It adds up pretty quickly, and in very short order you've sent back far more "duplicates" than you have actual valid results - in those first 10 passes, you've sent back 10 good results and 55 duplicates, and it only gets worse as time goes on.

Possibly other people returned few (hundred) thousand duplicates again this way...

Why should we be penilized because of a malfuncition of the seti servers.

I have run SetiDriver on all of my machines for years and didn't run into this problem at the end. Was this a version specific issue?

This seemed to have cleared up though, about the time that work units were no longer being sent to classic users.

About how big this problem could have been - not related to the specific poster, but just provided as an example. The machine mentioned in my previous post averaged about 9 work units per day, so using it as an example, here's what it might potentially have done had it not been caught after the first dupe was submitted (note that these are totals at the end of each day - not the number submitted on that particular day):

Day 1 - 9 good, 45 dupe
Day 2 - 18 good, 153 dupe
Day 3 - 27 good, 351 dupe
Day 4 - 36 good, 630 dupe
Day 5 - 45 good, 990 dupe
Day 6 - 54 good, 1431 dupe
Day 7 - 63 good, 1953 dupe
Day 8 - 72 good, 2556 dupe

I'm stopping at 8 days, since it was 8 days between they stopped sending results (Dec 15th) and stopped receiving results (Dec 23rd) - but you can see the trend. That was a P4/2.4 - if it were a faster machine, say one that was processing 16 work units per day (not uncommon), it's even worse and might look something like this (here again these are totals at the end of each day, not the number submitted on that particular day):

Day 1 - 16 good, 120 dupe
Day 2 - 32 good, 496 dupe
Day 3 - 48 good, 1128 dupe
Day 4 - 64 good, 2016 dupe
Day 5 - 80 good, 3160 dupe
Day 6 - 96 good, 4560 dupe
Day 7 - 112 good, 6216 dupe
Day 8 - 128 good, 8128 dupe

Of course, it's still all speculation, but it's given to provide a picture of just how large a single problem on a single machine can be if it's not noticed for several days.

I don't believe in the time period of 8 days that the seti servers would have accepted the duplicate results.

I don't believe in the time period of 8 days that the seti servers would have accepted the duplicate results.

Under normal circumstances, I doubt they would have - but during the last week or so of the project, they apparently were. I spoke with several people at the who noticed their WU count increasing too rapidly, and that's how we identified the third-party applications as the source of the problem.