LHC@home

The erroneous credit should be corrected as soon as possible but we should make sure malicious cheating was done before accusing anyone of cheating. (I'm from Canada where we believe in innocent until proven guilty.)

I agree that erroneous credit should be deleted as soon as possible.

I have little hesitation, however, in proposing drastic action against potential cheats. There is no need to comply with legal procedures or presumptions. I think project admins should be able to take any action they feel is in the best interest of the project; and they don't even have to be nice about it if they don't want to.

If that means an occassional innocent gets penalised then that is regrettable, but if said innocent cares about the science it should not matter. He/She can just create a new user-id and contribute again. There are no real-world consequences or harms inflicted.

I do think the potential presence of cheats fouls up the eco-system and could discourage non-cheats from contributing more. Any deterrent that prevents that, or reduces the risk, is a good thing.

Hi, I agree with former speakers, this should be impossible, displaying a
normal 'run-time' and an unusual large CPU-time!

If you were to drop the CPU speed to 1%, run-time would be affected, too.
I've seen weird situations running several projects, with (very) different
memory use, very high, >700MByte (Rosetta) per WU'.
Also the use of (a) GPU(s), if possible, is reducing CPU load,
time and (total)runtime.

And I agree that one is only guilty if proven so. And computers can display
weird or odd results, although, very uncommon.
When seriously OC'ed, heat, a gamma-ray :), etc.

Since I'm not familiar with the credit granting, anything with a 10 or 100
times higher runtime v.s. CPU time, or vice-versa, should raise a question and be looked at!

---

Knight Who Says Ni
N!

I support everybody demanding the cancellation of the amount of credit granted to those users!!
Most of us struggle hard to get some of the rare Work-unit so it takes weeks to get some thousand of credits.

---

Fred J. Verster,

You are ignoring some very important facts. There are an EXTREMELY HUGE number of positive and negative integers and alpha numeric strings that a random glitch or bug could write to the CPU time variable. In order to make the "innocent until proven guilty" argument stick you have to explain why, out of the trillions of possibilities, the bug writes only small positive integers. You also have to explain why this bug isn't seen more often because this software that has the "bug" is used by many thousands of crunchers at many different projects to crunch millions of tasks and there are thousands of eyes watching for abnormally large credit claims. You can't explain all of that by saying it's coincidence or luck.

Your idea of flagging results that have a CPU time 10 times higher than the run time will not stop cheating because the cheaters will simply cheat both numbers and make the run time slightly higher than the CPU time, as it normally is. Your suggestion would not catch that cheat.

Hello Admin?

Can the incorrect credit that was awarded to 4 users (due to the apparent work of one particular user, as stated in the opening few posts), please be corrected.
It is now 10 days since first posted.

It is not just the matter of a few hundred credits but many 10s of thousands of credits, which needs to be corrected before the work units are purged and you can't see what the problem was.

Thanks
Conan

---

Your idea of flagging results that have a CPU time 10 times higher than the run time will not stop cheating because the cheaters will simply cheat both numbers and make the run time slightly higher than the CPU time, as it normally is. Your suggestion would not catch that cheat.

It would if the project updated the CreditNew version to the latest, which caps both the p_fpops value and the runtime value.

Going at the users with the ferocity you're doing isn't going to help. Witch hunt here, witch hunt there, alienating people who try to help by coming up with alternative ideas, shooting them down from the hip.

Perhaps it's time for you to take some rest, away from the daily crap dealt to you with BOINC. Try playing The Elder Scrolls V: Skyrim, it's addictive and before you know it, days have passed, days that you don't need to be snippy at people you don't know, never met and by going at them like this, never will meet.

---

Jord

BOINC FAQ Service

Well the whole problem is when the project started it was using CreditNew with the lower of two users claims.

Several users complained about getting too little credit and wanted the method changed to average credit.

Now that the method has been changed, this has allowed cheaters in.

You can't keep every body happy either way.

Your idea of flagging results that have a CPU time 10 times higher than the run time will not stop cheating because the cheaters will simply cheat both numbers and make the run time slightly higher than the CPU time, as it normally is. Your suggestion would not catch that cheat.

It would if the project updated the CreditNew version to the latest, which caps both the p_fpops value and the runtime value.

As I mentioned earlier, if you cap any of the numbers you run the risk of disallowing legitimate claims if the caps are not high enough. No matter where you set the caps, cheaters will simply spoof their numbers to (cap - 1) and get away with it.

Going at the users with the ferocity you're doing isn't going to help. Witch hunt here, witch hunt there, alienating people who try to help by coming up with alternative ideas, shooting them down from the hip.

Your attempts to color my posts with negative words like ferocity, witch hunt, alienating, shooting, etc. don't wash. We're having a discussion of pros and cons here and if you don't like it then don't read it. People have brought up suggestions and I've told them why those suggestions won't work. Nothing wrong with that.

Perhaps it's time for you to take some rest, away from the daily crap dealt to you with BOINC. Try playing The Elder Scrolls V: Skyrim, it's addictive and before you know it, days have passed, days that you don't need to be snippy at people you don't know, never met and by going at them like this, never will meet.

BOINC doesn't deal me any crap, what are you talking about? I don't think I've been snippy but if I have then I apologize. Gaming is a waste of CPU cycles, IMHO.

You're absolutely right, Keith, you can't keep everybody happy. There's only 2 ways to stop cheating: get rid of credits completely or encrypt the client-side files that store the numbers cheaters spoof. I don't think Dave A. will get rid of credits. If he were to encrypt the files, people will complain that BOINC wastes CPU cycles encryting/decrypting files and that it's better to allow a little cheating than to waste those CPU cycles.

A third solution is to have projects use fixed credits determined solely by the server. That doesn't meet with approval from project admins because they couldn't care less about credits, don't want to be bothered with creating/coding a custom credit scheme to award credits they don't care about and feel that since Dave A implemented credits he should fix any credit related problems. Project admins also don't like the fact that some projects using their own credit scheme pay exorbitant credits to attract crunchers away from other projects. Everybody has a complaint but nobody has a solution that has broad support.

Regarding rolling back the rogue credits as suggested by Conan, project admins don't like doing that, especially if they're not familiar with database queries/writes. A few have screwed up their database trying to adjust credits and have been forced to revert to backups which usually negates legitimate credits earned for thousands of tasks after their screwup. Credits aren't their idea or their problem.

Geeez, where do you get the guts to speak on behalf of all the admins? They don't like this, they don't like that... You know all admins of all projects personally?
I think there are admins who care about attracting crunchers and who take a strong action against cheating. And there are those who don't care about credits, cheating, etc., ... well, good luck attracting crunchers. There was once a stubborn admin called DLB, who rather killed his project, then he would fix the cheating. He had a choice, and he made a choice. All other admins can follow his footsteps, and kill their projects. Or they can fix the cheating.

---

Maybe I get the guts the same way you get the guts to say that volunteers won't crunch without credits. Have you met all crunchers personally? How can you speak for them?

The fact is nobody has to meet with admins personally to understand what they think, you can just PM them. That is what I did and that's why I can claim to know what most of them want and think in regards to credits. How many crunchers have you discussed credits with? You seem to think you know what they all want but I bet you have heard from less than 5% of them.

Geeeez.

Here´s another one:
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=982128

Dear admins, please do something about that issue ...

---

Hello admins,

another four (till now) obscene mega-claims for this user:

http://lhcathomeclassic.cern.ch/sixtrack/hosts_user.php?userid=101328

This completely takes the fun out of watching the stats.

Please at least tell me (us) whether you intend to do something about the problem, that should not take to much of your (certainly valuable) time ...

Sincerely
Kai

---

The cheats for the tasks Kai has pointed out were accomplished by spoofing the elapsed and CPU times reported by BOINC client. About a week ago David Anderson released a server update or patch that prevents this type of cheat. If the Sixtrack admins can incorporate that patch/update into the current Sixtrack server setup then the "elapsed time and CPU time spoof" cheat will no longer work at Sixtrack.

It seems to me he could be running a 32-bit machine and if he sets the clock back to before the task started it will essentially be the unix time clock problem. If you go back 1 second you're logically going forward 2^32 seconds. Think Y2K only for unix time. If they were running 64-bit? Perhaps their machine is 64-bit but it's running the 32-bit app.

Again, I demand the project admins to delete those credits granted to that users!!!

---

This is ridiculous. These absurd credits need to be removed, and steps taken to prevent this in the future and deal with this user.

---

It seems to me he could be running a 32-bit machine and if he sets the clock back to before the task started it will essentially be the unix time clock problem. If you go back 1 second you're logically going forward 2^32 seconds. Think Y2K only for unix time. If they were running 64-bit? Perhaps their machine is 64-bit but it's running the 32-bit app.

The science app doesn't keep track of the time, BOINC does, so it makes no difference which science app he ran.

In the case of the second cheater Kai links to, the one with 4 high credit tasks, note that only the CPU time is affected. If it were due to the clock being set back then surely the elapsed time would have been affected too, I think.

Also, note the sent and returned times on the 4 tasks. 2 tasks were sent together, crunched and returned at the same time. Then another 2 were sent, crunched and returned. If the high CPU times are due to the clock being turned back after the tasks started then the clock must have been turned back twice, once while the first pair of tasks were crunching and again when the second pair were crunching. I could believe one clock adjustment but 2 in a row is not likely.

However, the biggest reason I don't believe the clock turn back theory is that it doesn't seem to affect a task's CPU time or it's elapsed time. I tried it and it has no effect but maybe I'm doing it wrong or maybe it's just my system. Can anybody out there make it work?

Crunchers crunch for various reasons. Some do it for science, some for the social aspects, some for the credits. All are welcome and all contribute to this community.

The actions of this new breed of cheaters may cause those that are in the "Credits" category of cruncher, to go to a different project and everyone suffers.

Additionally, the "Wingmen" who just received great credit boosts as well and have done nothing wrong, are now subject to scorn and accusations by those who don't understand the way credits are allocated. They don't deserve that either.

I strongly suggest that the management of the project do the following:

1. Delete the account of any cheater.
2. Re-Mark their tasks as errors, causing the WU to be reissued for validation. This will cause the science to completed, and the wingmen to get correct credit for their work.
3. Put the new protections in place on the server to keep our community cheater free.

---

Einstein@home is giving a fixed credit for each kind of task, gravitational wave search, binary radio pulsar search, gamma ray pulsar search, independently of the hardware employed and the time taken. I believe this to be the fairest way. Evidently those with a faster CPU/GPU can accomplish more work done in a given time period and thus gain more credits.
Tullio