Page 1 of 4

Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 1:18 pm
by Punchy
With the recent shift in AS allocations of bigadv units, it has again become "beneficial" in terms of points for users to cheat the system. By a number of means it is possible to receive WUs meant for <=12 core systems on larger systems. No, I can't prove it, but certain users' statistics don't lie - when all ethical SMP folders receive 100% p8101, while these other folders receive 0% p8101, it's pretty obvious.

Unlike the previous case of lying to the AS that you have MORE cores than you actually do, this one is detectable in that the completion times are far shorter than possible by the fastest actual 12 core systems.

An easy fix using already-existing code would be to reinstall the bonus cap on p6903/6904 down to a low value that is still slightly above that achievable by a true 12 core system. That would remove the incentive to cheat the assignment servers. The problem there would be when the rare 6903/4 slips through to a large system in a legitimate configuration, unless the bonus calculation can look at the claimed cores during assignment. Of course, if the bonus calculation CAN look at the claimed cores, a better bonus factor for such cases would be 0.

I'm curious if the Pande Group would actually do something about cheating in this case, rather than just saying "please don't do it" but with no repercussions. My suspicion is that the response will be that since 6903/4 are going away (which has been said for quite a few months now) no action will be taken, but I would be happy to be wrong.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 2:14 pm
by Skripka
So you want to cap points on the basis of something you cannot prove.

"I mean it is right there" is a line some scientists used in Prometheus, and that worked out well for them as we all know.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 2:26 pm
by Punchy
No, since I do not have access to the assignment server logs, I cannot prove it. However, I think that the probabilities involved do show manipulation. Do you believe that in a population of a few thousand, with a probability greater than 90% of getting 1 p8101, that several people can get 100% non-p8101?

If you had read what I posted, you would see that the action could take into account whether the case involved cheating or not.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 3:07 pm
by Jesse_V
Punchy wrote:No, I can't prove it, but certain users' statistics don't lie - when all ethical SMP folders receive 100% p8101, while these other folders receive 0% p8101, it's pretty obvious.
I'm calling "citation needed" on this one. I'm running SMP on a 4-core CPU and have received a variety of WUs, not just those from project 8101. I'm not cheating anywhere, so that disproves that, or am I misinterpreting your statement?

It makes sense to me that the PG is monitoring assigns and the balance of projects. The recent blog post supports this. I would think they would know if cheating or some other big imbalance was happening.

Also, how is what you're describing cheating?
And I'm sure there are many "true 12-core machines", all with different levels of performance. Which one would you choose to adjust the bonus cap?

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 3:16 pm
by Jonazz
Well if you have the username of the people you suspect doing this, one of the mods can always check it out.

It depends on what you call cheating, of course. They are folding these projects like they should, they only 'tweak' their settings so they get a certain number of projects. It doesn't really hurt the project, however the science goes slower because of this.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 4:23 pm
by 7im
Jesse_V wrote:
Punchy wrote:No, I can't prove it, but certain users' statistics don't lie - when all ethical SMP folders receive 100% p8101, while these other folders receive 0% p8101, it's pretty obvious.
I'm calling "citation needed" on this one. I'm running SMP on a 4-core CPU and have received a variety of WUs, not just those from project 8101. I'm not cheating anywhere, so that disproves that, or am I misinterpreting your statement?

It makes sense to me that the PG is monitoring assigns and the balance of projects. The recent blog post supports this. I would think they would know if cheating or some other big imbalance was happening.

Also, how is what you're describing cheating?
In the context of BA cheating, he meant this...
Punchy wrote:No, I can't prove it, but certain users' statistics don't lie - when all ethical [BA] SMP folders receive 100% p8101, while these other folders receive 0% p8101, it's pretty obvious.
And yes, WU blocking is a known cheating method, although I won't describe it, or the consequences of doing it, in any detail. I've seen it discussed openly in other forums. No citation needed, although I'm more than happy to provide one via PM. :twisted:

As for how it's considered cheating? Read the Best Practices FAQ.

#1, #3 and #4 cover it well. Gaming the system to change WU assignments is against the rules.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 5:33 pm
by Nathan_P
This is something that team bwm used to pull when the folded a couple of years ago. Given the current shortage of BA12 WU and the fact that you would also have to be running the core hack its a long winded way of gaining points. It is possible to run several gens of the same clone, i am currently doing the same on a 8101, having folded gens 19-21 and am currently on gen 22. i once ran a 6904 project that gave me 11 successive gens of the same clone.

I know which team you are referring to and if that was the case everyone with a BA rig on that team would be doing it. those folders may also be running powerful hardware.

Lots of reasons both legit and not legit, looking at EOC's points per update is hardly compelling evidence

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 5:40 pm
by Punchy
Sorry, I used SMP in the old school sense of multi-socket. Bigadv would have been a better way to describe it in this forum's terminology.

And, as I described the time threshold via the "fastest 12 core system", so it would make sense to set the cap based on that same "fastest" system. I'm sure we can find plenty of volunteers willing to show off their fast systems.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 5:43 pm
by Punchy
Nathan_P wrote:if that was the case everyone with a BA rig on that team would be doing it.
Not necessarily, I think in most teams there are a few who don't believe the rules apply to them, while the vast majority follow the rules.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 5:43 pm
by Nathan_P
JonazzDJ wrote:Well if you have the username of the people you suspect doing this, one of the mods can always check it out.

It depends on what you call cheating, of course. They are folding these projects like they should, they only 'tweak' their settings so they get a certain number of projects. It doesn't really hurt the project, however the science goes slower because of this.
The mod's will already have a fair idea as to who punchy is referring to :eo

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 5:48 pm
by 7im
Core hacking an AMD X6 up to 8 cores was common in the original BA program. Reversing the hack to make 48 cores look like 12 is just a simple edit to the same hack.

Speaking hypothetically, not everyone on any team is always of the same mind. Some are likely to forgo the hack. Not really proof either way.

Fortunately, that, and the PPD on EOC's page aren't the only analysis tools available.

Re: Detecting and defeating assignment server cheaters

Posted: Thu Jul 19, 2012 9:16 pm
by ChasR
As far as my recent experimentation in MP folding goes, I was able to completey avoid p8101 without cheating in any way. I used flags.

Re: Detecting and defeating assignment server cheaters

Posted: Fri Jul 20, 2012 2:45 am
by Punchy
ChasR wrote:As far as my recent experimentation in MP folding goes, I was able to completely avoid p8101 without cheating in any way. I used flags.
On a system with more than 12 cores, running bigadv-type work? If so, please share...

Re: Detecting and defeating assignment server cheaters

Posted: Fri Jul 20, 2012 10:24 am
by ChasR
On a 2P E5-2620 rig (12C/24T) running BA under v6.34 of the client. A moderator has kindly pointed out that I'm wrong about being succesful in avoiding p8101. My first 4 WUs weren't p8101, but my last truned in while on vacation was. Apparently there is no way to completely avoid them by non cheating means.

Edit:
Since memory failed and observation wasn't properly carried out regarding this issue, I reinstalled the temporary drive I was running FAH on and read the log. I installed FAH on July 4th and downloaded a p6903,and subsequently p6901, then got a string of 5 p8101s before removing FAH on July 16.

Re: Detecting and defeating assignment server cheaters

Posted: Fri Jul 20, 2012 4:19 pm
by brtaylor92
Punchy, I'd be curious to know how you can say with certainty that these people haven't been getting *any* p8101 at all? So far as I'm aware, there's no way to monitor what work units another folder is turning in, unless you work for Stanford. I suppose what I'm asking for is some elaboration on how you know these people are dodging units as opposed to adding new hardware, upgrading old hardware, or just generally not getting "many" p8101, for whatever qualifies as "many" to you. I find it hard to believe that *all* ethical big-adv folders are in fact receiving 100% p8101 when the p690x units haven't actually been phased out quite yet.