| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: The Clean Energy Project - Phase 2 Forum
Thread: Suspiciously short times on CEP2 work units |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 4
|
|
| Author |
|
|
ca05065
Senior Cruncher Joined: Dec 4, 2007 Post Count: 325 Status: Offline Project Badges: 
|
A few weeks ago there were problems with VINA work units being abused to gain above normal credits. I have noticed two instances of extremely short 'valid' work units on CEP2.
This is one currently in my results status pages which ran for less than an hour: E213172_ 273_ A.34.C28H15N3S3.21.4.set1d06_ 2-- 640 Valid 5/5/13 22:56:36 5/6/13 09:59:21 0.49 8.7 / 29.1 E213172_ 273_ A.34.C28H15N3S3.21.4.set1d06_ 1-- 640 Valid 5/5/13 22:51:06 5/6/13 13:45:44 7.14 214.6 / 126.2 E213172_ 273_ A.34.C28H15N3S3.21.4.set1d06_ 0-- 640 Error 5/5/13 22:44:11 5/5/13 22:49:51 0.00 0.0 / 0.0 My work unit ran for over 7 hours on an I7 2600K. Is someone trying to cheat in the challange which is about to start? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
No. The short work unit was validated against the other. Remember that each work unit is divided into 16 tasks of various lengths. If an error occurs, it stops and is returned. My guess is that the short work unit bombed out early in the third task, but was credited with the first 2 tasks that matched the other work unit.
The cheating method was to be awarded consolation points for a short invalid result. Since only 1 work unit could be run each day, the cheaters made far fewer points than if they had done the actual work. The cheaters were satisfied with the proof of their concept even though they lost points compared with honest crunchers. At least, that is what I hope happened. but there were possible improvements that would have allowed them to have made more points than they did, so we made several changes to discourage them. Lawrence |
||
|
|
pbenn1
Cruncher Joined: Mar 8, 2012 Post Count: 9 Status: Offline |
@ca05065 - once again Lawrence has hit it spang on. I have a device that does this little caper. This is what the standard error file reports:
Result Name: E213191_ 676_ C.34.C28H15N3S3.01566554.0.set1d06_ 1-- <core_client_version>6.10.58</core_client_version> <![CDATA[ <stderr_txt> INFO: No state to restore. Start from the beginning. [15:29:47] Number of jobs = 16 [15:29:47] Starting job 0,CPU time has been restored to 0.000000. [15:34:01] Finished Job #0 [15:34:01] Starting job 1,CPU time has been restored to 141.024904. [15:50:53] Finished Job #1 [15:50:53] Starting job 2,CPU time has been restored to 704.438116. Application exited with RC = 0x1 [18:42:30] Finished Job #2 [18:42:30] Starting job 3,CPU time has been restored to 6373.951258. [18:42:30] Skipping Job #3 (and all subsequent) Apparently the hex 1 return code flushes the rest of the stream, and the whole thing is over in a half hour. The short one is usually the copy 1 as it was in this example. |
||
|
|
ca05065
Senior Cruncher Joined: Dec 4, 2007 Post Count: 325 Status: Offline Project Badges:
|
Thank you for your re-assurance that nothing is wrong. The other job did fail about 300 seconds into job 2:
. . . [01:04:46] Finished Job #1 [01:04:46] Starting job 2,CPU time has been restored to 1491.578125. Application exited with RC = 0xc0000005 [01:11:14] Finished Job #2 [01:11:14] Starting job 3,CPU time has been restored to 1761.000000. [01:11:14] Skipping Job #3 . . . |
||
|
|
|