Dear Crunchers,

Yesterday, I had to suspend an account for two weeks and remove credits, for obvious credit cheating investigations. I'm quite annoyed that instead of doing science, I have to deal with this kind of behavior. We're small and we're short on time and it doesn't help scientific research...
EDIT : after investigations and fruitful exchanges, the problem has been identified and I'm sorry to have been a bit rough with this user.

The current credit system is too easy to fool, so I'm going to move to something simpler, robust and more generous on average: fixed credits. For short tasks (such as od9), I'm going to award 200 credits. This change requires draining the task queue. At that time, I will submit new tasks. These new tasks will be the opportunity to deploy the new code with checkpoints, system signals and affinity management for large systems (>32 cores). Some errors are to be expected, I can't test everything.

The last point concerns the requests for Gridcoin. I've been asked by the developers and by some of you. I am not against this possibility, but three points do not allow for the moment to be whitelisted. First, I can't guarantee to always have tasks waiting to be calculated. Secondly, the incentive to cheat will increase and I find that increasing the quorum is a waste of resources. Thirdly, I'm struggling with the server to keep it up. The upcoming arrival of larger molecules should settle the first point. For the second point, we are thinking about a validation by analyzing the result. I have already made many optimizations for the third point, at the moment it's much better.

Kindly
Benoit Da Mota

Very good. I never look at credits. Do what you want.

I have always thought fixed credits are the way to go. Sounds like a good plan.

---

Thank you for the affinity fix ... that will help :)

Yesterday, I had to suspend an account for two weeks and remove credits, for obvious credit cheating. I'm quite annoyed that instead of doing science, I have to deal with this kind of behavior. We're small and we're short on time and it doesn't help scientific research...

I like science and hate cheaters.
So, i'm waiting for new simulations...

Dear Crunchers,

Yesterday, I had to suspend an account for two weeks and remove credits, for obvious credit cheating. I'm quite annoyed that instead of doing science, I have to deal with this kind of behavior. We're small and we're short on time and it doesn't help scientific research...

The current credit system is too easy to fool, so I'm going to move to something simpler, robust and more generous on average: fixed credits. For short tasks (such as od9), I'm going to award 200 credits. This change requires draining the task queue. At that time, I will submit new tasks. These new tasks will be the opportunity to deploy the new code with checkpoints, system signals and affinity management for large systems (>32 cores). Some errors are to be expected, I can't test everything.

The last point concerns the requests for Gridcoin. I've been asked by the developers and by some of you. I am not against this possibility, but three points do not allow for the moment to be whitelisted. First, I can't guarantee to always have tasks waiting to be calculated. Secondly, the incentive to cheat will increase and I find that increasing the quorum is a waste of resources. Thirdly, I'm struggling with the server to keep it up. The upcoming arrival of larger molecules should settle the first point. For the second point, we are thinking about a validation by analyzing the result. I have already made many optimizations for the third point, at the moment it's much better.

Kindly
Benoit Da Mota

My suggestion would be to get with other Admins at other Projects and discuss both the User and how they are dealing with it, maybe even the folks at Seti as they are the ones where alot of people start crunching. You are not the first nor the last Project where people have tried to cheat, MOST get caught eventually. If a User is cheating here you can bet they're trying to cheat elsewhere too!! And yes being WhiteListed means a higher chance of people trying to cheat as it means more money in their pocket, that does NOT make GridCoin a bad thing it's just another thing for you Admins to be on the lookout for.

Dear Crunchers,

Yesterday, I had to suspend an account for two weeks and remove credits, for obvious credit cheating. I'm quite annoyed that instead of doing science, I have to deal with this kind of behavior. We're small and we're short on time and it doesn't help scientific research...

The current credit system is too easy to fool, so I'm going to move to something simpler, robust and more generous on average: fixed credits. For short tasks (such as od9), I'm going to award 200 credits. This change requires draining the task queue. At that time, I will submit new tasks. These new tasks will be the opportunity to deploy the new code with checkpoints, system signals and affinity management for large systems (>32 cores). Some errors are to be expected, I can't test everything.

The last point concerns the requests for Gridcoin. I've been asked by the developers and by some of you. I am not against this possibility, but three points do not allow for the moment to be whitelisted. First, I can't guarantee to always have tasks waiting to be calculated. Secondly, the incentive to cheat will increase and I find that increasing the quorum is a waste of resources. Thirdly, I'm struggling with the server to keep it up. The upcoming arrival of larger molecules should settle the first point. For the second point, we are thinking about a validation by analyzing the result. I have already made many optimizations for the third point, at the moment it's much better.

Kindly
Benoit Da Mota

My suggestion would be to get with other Admins at other Projects and discuss both the User and how they are dealing with it, maybe even the folks at Seti as they are the ones where alot of people start crunching. You are not the first nor the last Project where people have tried to cheat, MOST get caught eventually. If a User is cheating here you can bet they're trying to cheat elsewhere too!! And yes being WhiteListed means a higher chance of people trying to cheat as it means more money in their pocket, that does NOT make GridCoin a bad thing it's just another thing for you Admins to be on the lookout for.

+1


I like fixed credit, thank you for that. I hate cheaters as well. I don't do gridcoin, so I'm ok not going that route. I'm more into trying to help solving complex problems.

Wow and the user wasn't even Gridcoin.

Works for me :)

No one was cheating. Nice way to jump to conclusions.

No one was cheating. Nice way to jump to conclusions.

The thread title, from the admin of the project, has the word cheating.

No one was cheating. Nice way to jump to conclusions.

And you know this HOW exactly?

The admin of this project would not publically state that they found someone was cheating if they did not have some proof.

And I prefer to believe the project admins, unless you can prove otherwise.

Cheaters bring down the whole idea of volunteer computing and give it a bad name, when we offer our computer time to improve science and other worthy projects, rather than waste their time having to 100% check and perhaps then double check all results and to then have to suspend cheaters for their wrong doing.

Wow and the user wasn't even Gridcoin.

mmmmmm....are you sure about that?

Please don't turn this thread into a brawl.

I never said the cheating came from Gridcoin. Besides, it was a Gridcoin developer who advised me to tighten up the verification. He made it clear that, yes, putting the project on the white list could increase the risk of cheating, but even without it, cheating exists on BOINC.

No one was cheating. Nice way to jump to conclusions.

You're right, for lack of time, I jumped to the conclusion very quickly. I exchanged courteous e-mails with the user. I always give the benefit of the doubt and in this case the truth is more subtle. His intention was not to cheat on credits, but to store a lot of work units. From my point of view (and I told him), it is also a form of cheating because it disadvantages other users, but even if I disapprove, this practice is tolerated. However, the allocation of credits was completely screwed up and we agreed on a reasonable amount of points for him and his team. Of course, the ban is going to be lifted and I would like to take this opportunity to make a public mea culpa. I'm new to managing a BOINC project and I didn't manage this crisis the best I could. Sorry !

This episode had the advantage of highlighting the weakness of the credit system. I spent yesterday developing and testing the fixed credit system and quorum validation. The new code seems to work well (no less well than the old one at least).

Wow and the user wasn't even Gridcoin.

mmmmmm....are you sure about that?

There was 1 user with negative 1.2mil credit on the day the admin said it was removed. A former team member whom I would not have guessed to be a cheater.

Many would prefer a fixed credit system especially for nearly equal run times but run times all over the place for this project.

You're right, for lack of time, I jumped to the conclusion very quickly. I exchanged courteous e-mails with the user. I always give the benefit of the doubt and in this case the truth is more subtle. His intention was not to cheat on credits, but to store a lot of work units.

You can, if you want, limit wus per host very easily
https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Joblimits

I am sorry that something like this happened. Possible cheating is a great hanging sword over my project as well, because I do not use quorum either.
And dealing with credit is very annoying for project admins. I had finally settled on awarding credits based on counters of internal operations that the app keeps.
I did not think that you would have problems keeping up the load at 4 times less FLOPs than mine has, but if your assimilator is scrip and does expensive file operations, it could very well be.

I did not think that you would have problems keeping up the load at 4 times less FLOPs than mine has, but if your assimilator is scrip and does expensive file operations, it could very well be.

Thank you for your tips. For this project, each task generates 10-20 MB of output files and therefore intensive file operations is the weak point from the server side.

Glad everything was sorted out.

Hi all,

To be honest, I don't really like the idea of Gridcoin in science projects BUT if it can help people helping compute... why not.

As far as I'm concerned, I ditched something like 15-ish tasks because I submitted 8 jobs yesterday and nothing seems to validate... so nothing for science.
I'll be switching to Debian as soon as possible for all my BOINC projects.

I don't really care about credits. Of course it's always nice to be rewarded and to be considered for the interest put in the project so credits might be attracting for some people.

Fix credits seems to be a good idea actually. People interested in credits know where they are going at least.

Thanks for reading my message ; it's only my opinion but... I don't know. Ditching some projects frightens me a bit.. don't want to have trouble because of that espcecially if it's for the better (going full Linux for BOINC).

Best regards,

micropro