Message boards :
Number crunching :
Faulty Computers or Modified BOINC ?? Huge Credits
Message board moderation
Author | Message |
---|---|
Send message Joined: 6 Jul 06 Posts: 108 Credit: 663,175 RAC: 0 |
Two users computers have come in with amazing results in the last few days. MrOctane and Bartonn Have both returned results that have shot there totals to 1 million credits. Incredible amount of CPU time of over 380 MILLION Seconds CPU time, bit impossible (this was on Bartonn as MrOctane is hidden). Over 900,000 credits granted per user. Possible computer mistakes? Can this be checked please, seems very odd. Conan |
Send message Joined: 22 Jul 05 Posts: 72 Credit: 3,962,626 RAC: 0 |
Two users computers have come in with amazing results in the last few days. Always better to give a link so others can easily follow. This is Bartonn's task list and something is screwing up the CPU time whilst the run time looks OK. As a result of the crazy claims made by this host, there would now be three wingmen who have gotten a rather unexpected and exceedingly large bonus, with more to come as the host completes more tasks. I'm guessing you saw the two names you mentioned by looking at those two right up the top of the list for the top performers based on RAC. There are only those two at the moment but there will be two more lucky lottery winners shortly when the newly completed mega-credits are taken into account. Perhaps there's no malice involved. I wonder if it could be something to do with a date change while tasks were in progress?? Cheers, Gary. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
Probably they spoofed the CPU time and elapsed time. It's very easy to do, I know because I've done it myself. It doesn't require a modified client or spoofing the benchmarks. MrOctane's computers are hidden. Here's the last three results from Bartonn: 1656325 763015 18 Nov 2011 21:43:22 UTC 19 Nov 2011 16:58:35 UTC Completed and validated 26,805.14 368,523,700.00 1,965,981.01 983,069.50 SixTrack v530.10 1656282 762993 18 Nov 2011 21:43:22 UTC 20 Nov 2011 2:08:56 UTC Completed and validated 26,382.96 152,328,300.00 812,633.07 406,388.01 SixTrack v530.10 1656260 762982 18 Nov 2011 21:44:12 UTC 20 Nov 2011 7:06:52 UTC Completed and validated 26,337.58 230,607,600.00 1,230,233.39 615,194.97 SixTrack v530.10 Notice task 1656325 was on his computer for less than 24 hours but somehow racked up 4,265 days of CPU time. Well, that might have been due to some book keeping error on BOINC's part but the other two results show the same kind of "mistake". Once maybe, twice highly unlikely, thrice... he's busted. Shorty, get the rope. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
I wonder if it could be something to do with a date change while tasks were in progress?? If it were due to a date change, CPU time and elapsed time would both be affected. Elapsed time for Bartonn's tasks appears to be normal. Why? Because he/she spoofed the CPU time but ignored the elapsed time. I give him A for effort but D for execution. Bartonn has to learn to pay attention to detail if he expects to gain respect as a master cheater. |
Send message Joined: 3 Oct 11 Posts: 3 Credit: 0 RAC: 0 |
if he expects to gain respect as a master cheater. You don't get or deserve respect when you cheat on any Boinc project regardless of which ID you are using. And you shouldn't get any credit for hundreds of posts added to the credit cheating. Here or any other project even if you call it a "test" over and over. >;-) |
Send message Joined: 6 Jul 06 Posts: 108 Credit: 663,175 RAC: 0 |
Two users computers have come in with amazing results in the last few days. Yeah forgot the link also it wasn't 380 Million seconds but 368 MILLION seconds. Small detail but one must be correct as possible. 4 other people have now benefited from the claims of Bartonn, so the credit blow out is expanding as Gary has stated. Conan |
Send message Joined: 14 Jul 08 Posts: 4 Credit: 2,377,539 RAC: 0 |
I was looking for how I could report this as a problem when I noticed this thread. My claimed credit for WU 763015 is 157.99 with a granted credit of 983,000. Please feel to take back any incorrect credits, I'm on the up and up. |
Send message Joined: 14 Jul 08 Posts: 4 Credit: 2,377,539 RAC: 0 |
I've also shown my computers, just for good measure. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
With your computers exposed it's easy to see what you said is true, you got your big boost because you were Bartonn's wingman on a WU he/she cheated on. Your benchmarks, elapsed time and CPU time are all realistic. |
Send message Joined: 22 Jul 05 Posts: 72 Credit: 3,962,626 RAC: 0 |
Bartonn has several hosts attached to the project and these are not hidden. If he was a master cheater, his hosts would be hidden, he would have chosen a rather less conspicuous amount to cheat by and he would have spread this over all the hosts he has. The host that had the glitch is a quad core and exactly 4 tasks showed the glitch. It's possible that those 4 tasks were all running and were affected when the glitch occurred. The host has received more tasks since the original 4 were returned and now the CPU time seems to be normal. Looks pretty much like it was just one of those unfortunate and unexplained events. It may well be that Bartonn doesn't even know the problem has occurred. We can now identify the 4 lucky recipients of this unintended largesse - MrOctane, wdsmia, Inargus and Galeon 7. Just look at the top 5 names based on RAC. Two of them are on top based on total credit as well. Looks like there needs to be a sanity check on credit claims to prevent this sort of thing happening again. Cheers, Gary. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
Bartonn has several hosts attached to the project and these are not hidden. If he was a master cheater, his hosts would be hidden, he would have chosen a rather less conspicuous amount to cheat by and he would have spread this over all the hosts he has. The host that had the glitch is a quad core and exactly 4 tasks showed the glitch. It's possible that those 4 tasks were all running and were affected when the glitch occurred. As I pointed out earlier, Bartonn is NOT a master cheater and that's why he failed to hide his hosts and failed to make it look like a glitch. As for the amount of his cheat, does a bank robber take less in hopes that a lesser amount will go unnoticed? Nooo, he reasons that if if he's going to risk gaol he would rather have a substantial reward rather than a pittance. Or maybe Bartonn just doesn't care if he is discovered or thinks that he will not be discovered. Most criminals think they have the perfect plan and will never be caught. The only glitch that would affect all four tasks would be a date change and I am quite sure that a date change would have affected the elapsed time as well as the CPU time. To prove/disprove the hypothesis I advanced the date on my host by two days after two Sixtrack tasks started. When those tasks finish, if their CPU time and elapsed time are *both* two days more than they should be then that pretty much proves there was no glitch on Bartonn's host and that he/she spoofed the CPU time but neglected to spoof the elapsed time. The host has received more tasks since the original 4 were returned and now the CPU time seems to be normal. Looks pretty much like it was just one of those unfortunate and unexplained events. It may well be that Bartonn doesn't even know the problem has occurred. Or Bartonn decided to not spoof the CPU time on the last tasks. Or they finished and uploaded while he slept which made it impossible for him to spoof them. Bartonn would like you to believe this was just an unfortunate and unexplainable event, a glitch, but I intend to prove otherwise. We can now identify the 4 lucky recipients of this unintended largesse - MrOctane, wdsmia, Inargus and Galeon 7. Just look at the top 5 names based on RAC. Two of them are on top based on total credit as well. Looks like there needs to be a sanity check on credit claims to prevent this sort of thing happening again. A sanity check won't work. If you limit the acceptable CPU time then you must set the limit high enough to allow slow hosts to submit their CPU time, which will always be high, and have it accepted. If that limit is X then cheaters can simply spoof all their CPU times as high as X and get away with it. Since cheating involves meddling with client_state.xml and other files, it has been suggested that those files should be encrypted to thwart meddling. That won't work either because someone will break the encryption. Or, as has happened in the past, people will alter the benchmark code in the client source and inflate the benchmarks. You can't refuse that hosts's claims because you can never be sure the CPU isn't severely overclocked. The only way to eliminate cheating is to ignore host benchmarks, times and credit claims and determine credits on the server, i.e. fixed credits. But then you get renegade projects giving huge credit payouts to attract crunchers away from other projects which is nothing less than cheating. There is only one answer for all this... eliminate credits. Kick the whole idea of credits into a ditch, shoot it, bury it and forget about it. |
Send message Joined: 3 Oct 06 Posts: 101 Credit: 8,994,586 RAC: 0 |
There is only one answer for all this... eliminate credits... I do not agree. ;-) This project needs safe granting and nothing more! STEP 1 (mandatory) If Claimed2>=Claimed1 Then Granted=Claimed1 Else Granted=Claimed2 End If STEP 2 (optional) If Claimed2>=Claimed1 Then Ratio=Claimed2/Claimed1 Else Ratio=Claimed1/Claimed2 End If If Ratio<=1+ValueAcceptable Then Granted=(Claimed1+Claimed2)/2 End If That is all... Found a bug? If so then fix it... :-) |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
@ metalius, Your methods would work here but not projects that have a quorum of 1 and there are lots of projects in that category. Regarding the affect of a date change on the CPU time and elapsed time... there is no affect. Check result 1670580 on the results list for host 9940966 and see that the CPU time and elapsed time are normal. Results 1670773 and 1670647 were also running when I advanced the date but those two are not complete yet. The affect on their times will be the same... no affect. If there were a glitch that could cause CPU time but not elapsed time to be altered it would have been noticed by now. There are simply too many computers and too many eyes watching for such a glitch to go unnoticed and unreported. Also, a glitch is just as likely to write garbage, for example 8&sm9~ldn84)Mc%^ujp3457, yet all 4 of Bartonn's tasks that were supposedly affected by this glitch had sensible values (though unreasonable values) rather than garbage. Bartonn altered the CPU time, not some glitch. Do I care? Not in the least. Credits are all about competition and seeing who can cheat the best and not get caught is great competition and totally harmless since the credits are worthless. |
Send message Joined: 10 Apr 06 Posts: 7 Credit: 69,019 RAC: 0 |
And what with this WU on this computer of this this owner. Run time 4.19 s, cpu time 76,004.08 s Either there are more cheaters, or we have a bug. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
His wingman completed the task in 7 secs run time, 5 secs CPU time. His machine reports 4 secs run time and 76,004 secs (21 hrs) CPU time. The small discrepancy between run times is not abnormal but the huge discrepancy between the two CPU times and the huge discrepancy between his own CPU and run times is very abnormal. I call cheat, for the same reasons I call Bartonn's tasks cheats. |
Send message Joined: 22 Jul 05 Posts: 72 Credit: 3,962,626 RAC: 0 |
What's just as interesting is that the two tasks were both awarded the full credit value rather than being awarded the average. Surely that's a bug?? It's a bit concerning that there doesn't seem to be any interest or reaction by HQ to the more massive problem caused by the Bartonn rogue results. The site stats are now so screwed that it may have an adverse reaction on participant satisfaction, let alone the 'encouragement' factor to those with malicious intent. I would have thought that some action to reverse the rogue credits could well pay off in discouraging 'copycat' offenders. Cheers, Gary. |
Send message Joined: 10 Apr 06 Posts: 7 Credit: 69,019 RAC: 0 |
I am his wingman and I was very surprised with that WU and I don't know, why we were not granted an average - what I know is that I did not anyhow manipulate anything. I would not call him a cheater so fast - see his other tasks - no other issues, but this one. Maybe someone from the project should look closer into it, because there maybe a strange bug, which spoils the whole LHC's credit system at the moment. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
I am his wingman and I was very surprised with that WU and I don't know, why we were not granted an average - what I know is that I did not anyhow manipulate anything. There is no doubt about it.. you're innocent. I would not call him a cheater so fast - see his other tasks - no other issues, but this one. All that proves is that he didn't cheat on his other tasks. He cheated on the one task out of curiosity, to see if his cheat method works and/or to see if he would be caught. Maybe someone from the project should look closer into it, because there maybe a strange bug, which spoils the whole LHC's credit system at the moment. Nobody from the project cares about the credits, that's why they use the CreditNew system. CreditNew is built into the server code so projects can concentrate on the science and forget about the credits. If it's buggy or can be cheated it's Dave Anderson's fault so they probably prefer that you tell him about it. One thing is sure, if they don't fix the rogue credits while the WUs are still in the database there won't be a way to fix them later. |
Send message Joined: 4 Dec 08 Posts: 8 Credit: 7,182,808 RAC: 6,556 |
I am one of Bartonn's wingmen. I sent a PM to one of the project admins and got a message back from him saying that he was the right person to send such a message to but that he was busy and would look into it when he had time. In the meantime I am reluctant to call Bartonn a cheater without some kind of an investigation. His behavior as described above is not consistent with a real cheater and only 4 WU's were affected. 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.) His CPU time appears to be 10,000 times higher than it should and could be due to a bug in the credit code or cheating. I don't have any way of determining which and am willing to leave it up to the project admins to correct. If there is a second machine exhibiting the same behavior now then maybe there is a code problem. |
Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
Or maybe a second person has discovered the cheat method. I think Bartonn's behavior is very consistent with the behavior of a cheater who does not know how to spoof the benchmarks and that is exactly what Bartonn did not do, he spoofed the CPU time instead because he doesn't know how to spoof benchmarks. If you know how to spoof benchmarks then you only have to do it once and all reults after that will be cheats. Spoofing the CPU time or elapsed time requires ongoing effort. You have to spoof the numbers for each and every result and it's not hard but it's very inconvenient and it throws a bit of a monkey wrench into the rest of your projects. Therefore a person might do it once to see if it works and do a BIG cheat and then decide the procedure just isn't worth the ongoing effort it requires. If you knew the cheat method, as I do, you would see precisely why a person would cheat 3 results then not do it again for a while. I live in Canada too and I believe in innocent until proven guilty too but when an action cannot be explained any other way than to say it was deliberate then I tend to believe it was deliberate. The rogue results we are talking about here were not a glitch/bug on the server, they were due to a glitch/bug/cheat on the client where the CPU time was recorded. The server simply accepts whatever CPU time the client reports and uses it to calculate credits. If the number was altered on the client then it is extremely unlikely it was due to a bug/glitch because those most often write random strings such as k4uc843n67 dsmnads9g%mm (that is not a typo, it is exactly what I meant to type) rather than proper numbers. |
©2024 CERN