| 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: WCG can be a mysterious judge at time...[RESOLVED] |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 10
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Consider, for instance, my log for E207129_ 977_ C.26.C22H14N2SSi.01928398.3.set1d06_ 1--
----------------------------------------Result Name: E207129_ 977_ C.26.C22H14N2SSi.01928398.3.set1d06_ 1-- <core_client_version>6.10.58</core_client_version> <![CDATA[ <stderr_txt> INFO: No state to restore. Start from the beginning. [09:27:32] Number of jobs = 16 [09:27:32] Starting job 0,CPU time has been restored to 0.000000. [09:29:17] Finished Job #0 [09:29:17] Starting job 1,CPU time has been restored to 101.993454. [09:34:15] Finished Job #1 [09:34:15] Starting job 2,CPU time has been restored to 396.445341. [12:24:57] Finished Job #2 [12:24:57] Starting job 3,CPU time has been restored to 10534.872331. [12:30:50] Finished Job #3 [12:30:50] Starting job 4,CPU time has been restored to 10883.550166. [12:35:13] Finished Job #4 [12:35:13] Starting job 5,CPU time has been restored to 11145.023442. [12:39:53] Finished Job #5 [12:39:53] Starting job 6,CPU time has been restored to 11421.800416. [12:44:15] Finished Job #6 [12:44:15] Starting job 7,CPU time has been restored to 11681.495281. [12:49:57] Finished Job #7 [12:49:57] Starting job 8,CPU time has been restored to 12020.532254. [12:54:12] Finished Job #8 [12:54:12] Starting job 9,CPU time has been restored to 12273.519076. [12:58:52] Finished Job #9 [12:58:52] Starting job 10,CPU time has been restored to 12551.512858. [13:08:08] Finished Job #10 [13:08:08] Starting job 11,CPU time has been restored to 13104.552003. [13:13:28] Finished Job #11 [13:13:28] Starting job 12,CPU time has been restored to 13422.060838. [13:49:58] Finished Job #12 [13:49:58] Starting job 13,CPU time has been restored to 15602.096813. [14:58:47] Finished Job #13 [14:58:47] Starting job 14,CPU time has been restored to 19719.337605. [16:08:58] Finished Job #14 [16:08:58] Starting job 15,CPU time has been restored to 23916.731711. [17:33:21] Finished Job #15 17:33:27 (1088): called boinc_finish </stderr_txt> ]]> Now consider my wingman's log for E207129_ 977_ C.26.C22H14N2SSi.01928398.3.set1d06_ 0--Result Name: E207129_ 977_ C.26.C22H14N2SSi.01928398.3.set1d06_ 0-- <core_client_version>7.0.3</core_client_version> <![CDATA[ <stderr_txt> INFO: No state to restore. Start from the beginning. 22:39:32 (8204): No heartbeat from core client for 30 sec - exiting 22:39:33 (8204): No heartbeat from core client for 30 sec - exiting 22:39:34 (8204): No heartbeat from core client for 30 sec - exiting 22:39:35 (8204): No heartbeat from core client for 30 sec - exiting 22:39:36 (8204): No heartbeat from core client for 30 sec - exiting 22:39:37 (8204): No heartbeat from core client for 30 sec - exiting 22:39:38 (8204): No heartbeat from core client for 30 sec - exiting 22:39:39 (8204): No heartbeat from core client for 30 sec - exiting 22:39:40 (8204): No heartbeat from core client for 30 sec - exiting 22:39:41 (8204): No heartbeat from core client for 30 sec - exiting 22:39:42 (8204): No heartbeat from core client for 30 sec - exiting 22:39:43 (8204): No heartbeat from core client for 30 sec - exiting 22:39:44 (8204): No heartbeat from core client for 30 sec - exiting 22:39:45 (8204): No heartbeat from core client for 30 sec - exiting [22:42:40] Number of jobs = 16 [22:42:40] Starting job 0,CPU time has been restored to 0.000000. No heartbeat: Exiting [22:42:41] Number of jobs = 16 [22:42:41] Starting job 0,CPU time has been restored to 0.000000. [22:44:54] Finished Job #0 [22:44:54] Starting job 1,CPU time has been restored to 111.275513. [22:51:00] Finished Job #1 [22:51:00] Starting job 2,CPU time has been restored to 443.058440. 00:34:40 (9488): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [00:34:45] Number of jobs = 16 [00:34:45] Starting job 2,CPU time has been restored to 443.058440. 01:19:44 (9368): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [01:19:46] Number of jobs = 16 [01:19:46] Starting job 2,CPU time has been restored to 443.058440. 01:59:48 (9908): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [01:59:53] Number of jobs = 16 [01:59:53] Starting job 2,CPU time has been restored to 443.058440. 04:40:59 (9620): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:41:35] Number of jobs = 16 [04:41:35] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [04:42:41] Number of jobs = 16 [04:42:41] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [04:45:44] Number of jobs = 16 [04:45:44] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [04:50:47] Number of jobs = 16 [04:50:47] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [04:56:50] Number of jobs = 16 [04:56:50] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [05:04:52] Number of jobs = 16 [05:04:52] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [05:18:56] Number of jobs = 16 [05:18:56] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [05:40:01] Number of jobs = 16 [05:40:01] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [06:04:06] Number of jobs = 16 [06:04:06] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [06:19:09] Number of jobs = 16 [06:19:09] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [06:35:12] Number of jobs = 16 [06:35:12] Starting job 2,CPU time has been restored to 443.058440. Quit requested: Exiting [06:56:17] Number of jobs = 16 [06:56:17] Starting job 2,CPU time has been restored to 443.058440. [10:37:39] Finished Job #2 [10:37:39] Starting job 3,CPU time has been restored to 11938.943731. [10:45:16] Finished Job #3 [10:45:16] Starting job 4,CPU time has been restored to 12342.518318. [10:51:03] Finished Job #4 [10:51:03] Starting job 5,CPU time has been restored to 12642.898244. Quit requested: Exiting [04:12:45] Number of jobs = 16 [04:12:45] Starting job 5,CPU time has been restored to 12642.898244. 04:14:17 (31084): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:14:27] Number of jobs = 16 [04:14:27] Starting job 5,CPU time has been restored to 12642.898244. 04:16:11 (31944): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:16:42] Number of jobs = 16 [04:16:42] Starting job 5,CPU time has been restored to 12642.898244. 04:19:14 (28692): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:19:17] Number of jobs = 16 [04:19:17] Starting job 5,CPU time has been restored to 12642.898244. 04:21:12 (28332): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:22:00] Number of jobs = 16 [04:22:00] Starting job 5,CPU time has been restored to 12642.898244. 04:26:12 (32428): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:27:30] Number of jobs = 16 [04:27:31] Starting job 5,CPU time has been restored to 12642.898244. 04:30:37 (9632): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:30:47] Number of jobs = 16 [04:30:47] Starting job 5,CPU time has been restored to 12642.898244. 04:36:14 (31396): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:37:39] Number of jobs = 16 [04:37:39] Starting job 5,CPU time has been restored to 12642.898244. 04:41:12 (29936): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:41:15] Number of jobs = 16 [04:41:15] Starting job 5,CPU time has been restored to 12642.898244. 04:46:10 (28644): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:46:16] Number of jobs = 16 [04:46:16] Starting job 5,CPU time has been restored to 12642.898244. 04:50:07 (31168): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:51:14] Number of jobs = 16 [04:51:14] Starting job 5,CPU time has been restored to 12642.898244. 04:51:44 (30592): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:55:44] Number of jobs = 16 [04:55:44] Starting job 5,CPU time has been restored to 12642.898244. 04:56:50 (29604): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [04:57:22] Number of jobs = 16 [04:57:22] Starting job 5,CPU time has been restored to 12642.898244. 04:58:23 (29368): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:02:46] Number of jobs = 16 [05:02:47] Starting job 5,CPU time has been restored to 12642.898244. 05:04:25 (27952): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:04:41] Number of jobs = 16 [05:04:41] Starting job 5,CPU time has been restored to 12642.898244. 05:06:52 (30772): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:07:49] Number of jobs = 16 [05:07:50] Starting job 5,CPU time has been restored to 12642.898244. 05:12:14 (31816): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:12:31] Number of jobs = 16 [05:12:31] Starting job 5,CPU time has been restored to 12642.898244. 05:13:20 (30268): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:13:41] Number of jobs = 16 [05:13:41] Starting job 5,CPU time has been restored to 12642.898244. 05:14:57 (29200): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:15:29] Number of jobs = 16 [05:15:29] Starting job 5,CPU time has been restored to 12642.898244. 05:17:05 (28472): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:17:20] Number of jobs = 16 [05:17:20] Starting job 5,CPU time has been restored to 12642.898244. 05:18:21 (30172): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:19:55] Number of jobs = 16 [05:19:55] Starting job 5,CPU time has been restored to 12642.898244. 05:23:22 (32376): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:25:21] Number of jobs = 16 [05:25:21] Starting job 5,CPU time has been restored to 12642.898244. 05:28:39 (31360): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:28:51] Number of jobs = 16 [05:28:51] Starting job 5,CPU time has been restored to 12642.898244. 05:32:00 (7440): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:32:44] Number of jobs = 16 [05:32:44] Starting job 5,CPU time has been restored to 12642.898244. 05:33:39 (32216): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:35:36] Number of jobs = 16 [05:35:36] Starting job 5,CPU time has been restored to 12642.898244. 05:37:58 (31664): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:38:19] Number of jobs = 16 [05:38:19] Starting job 5,CPU time has been restored to 12642.898244. 05:39:23 (32464): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:40:03] Number of jobs = 16 [05:40:03] Starting job 5,CPU time has been restored to 12642.898244. Application exited with RC = 0x1 [05:41:32] Finished Job #5 [05:41:32] Starting job 6,CPU time has been restored to 12678.466472. [05:41:40] Skipping Job #6 [05:41:40] Starting job 7,CPU time has been restored to 12678.466472. [05:41:50] Skipping Job #7 [05:41:50] Starting job 8,CPU time has been restored to 12678.466472. 05:41:56 (29992): No heartbeat from core client for 30 sec - exiting [05:42:01] Skipping Job #8 [05:42:01] Starting job 9,CPU time has been restored to 12678.466472. 05:42:02 (29992): No heartbeat from core client for 30 sec - exiting 05:42:03 (29992): No heartbeat from core client for 30 sec - exiting [05:42:03] Skipping Job #9 [05:42:03] Starting job 10,CPU time has been restored to 12678.466472. [05:42:04] Skipping Job #10 [05:42:04] Starting job 11,CPU time has been restored to 12678.466472. [05:42:04] Skipping Job #11 [05:42:04] Starting job 12,CPU time has been restored to 12678.466472. 05:42:04 (29992): No heartbeat from core client for 30 sec - exiting No heartbeat: Exiting [05:43:23] Number of jobs = 16 [05:43:23] Starting job 12,CPU time has been restored to 12678.466472. Application exited with RC = 0x1 [05:45:26] Finished Job #12 [05:45:26] Starting job 13,CPU time has been restored to 12729.260398. [05:45:26] Skipping Job #13 [05:45:26] Starting job 14,CPU time has been restored to 12729.260398. [05:45:27] Skipping Job #14 [05:45:27] Starting job 15,CPU time has been restored to 12729.260398. [05:45:29] Skipping Job #15 05:46:41 (31516): called boinc_finish </stderr_txt> ]]> If you were to guess that my result was judged to be "Valid" based upon the successful completion in the first log and my wingman's result was judged to be "Invalid" based upon the unending stream of errors in the second log, you'd be wrong. I would note that I am using client 6.10.58 and my wingman is using client 7.0.3....if you're like me, you see that and go "Huh...wonder how often that is happening to results...wonder how many have been lost." [Edit 1 times, last edit by Former Member at Apr 26, 2012 2:08:25 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
1. The assumption that invalid results are lost is disturbing. They're not. They go to cleanenergy directly and from recollection analyze all data and run any again that have a modicum of interest in their result, that is the invalid included that ran to the end. Credits rules at WCG are just for that purpose... to tell the volunteer (s)he did X time, for Y points.
2. The validation rules are set with full collaboration of the project owners. They determine what's checked and the tolerances. 3. Am missing the quorum detail in the OP, to see who got what. The garble (possible a Linux host as these seem to do that when pulling text files into an editor), suggests the result with the heartbeat problem did manage to compute a number of jobs, albeit seemingly having issue when restoring for the next one. Heartbeat implies that system was overloaded (signal 11 then often gets logged). Whilst whoever took early alpha developer client 7.03 into a production that long is taking chances, BUT, the client does not do the computing, the cleanenergy science app does. Clients are just high level task managers, queuing work units up in time and sending results back. 7 just has more bells under the hood, substantially improving the client/server interaction efficiency and more, so much so that it may get adopted by WCG, once the cycle has matured this one to an SP1 or SP2 level, which is thought to be like Q4-2012 (we hope). What it's really now is RC1 (at 7.0.25). --//-- BTW, I've decided [for myself] that Linux as platform is not up to the job FA CEP2 is concerned. If I run it, I boot to W7-64 which gives me 99+% efficiency on 6 year old hardware, 4 (all core) concurrent, opposed to the 93% or much worse when the system is even lightly used under Linux Ubuntu. |
||
|
|
Hypernova
Master Cruncher Audaces Fortuna Juvat ! Vaud - Switzerland Joined: Dec 16, 2008 Post Count: 1908 Status: Offline Project Badges: 
|
The moment I opened this thread, I got such a big headache. My view got blurred and had a kind of nausea.
---------------------------------------- Btw what is the question   |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
1. The assumption that invalid results are lost is disturbing. They're not. They go to cleanenergy directly and from recollection analyze all data and run any again that have a modicum of interest in their result, that is the invalid included that ran to the end. Credits rules at WCG are just for that purpose... to tell the volunteer (s)he did X time, for Y points. Good to know that CEP2 (and all projects, for that matter) do a 100% review of results looking for anomalies. I've found that most systems are automated in order to eliminate the need for a 100% review.I would think it wise, however, to publicize the fact that a successful, error-free work unit completion will not necessarily result in the "normal" amount of points being awarded...as you know, an "Invalid" result is docked 50% of its points. Further, I would suggest that you publicize the fact that reviewing your results to determine the cause of "Invalid" results is pointless...a clean-and-green log is not indicative of a result that carries more weight for validation purposes than does a log riddled with errors and non-zero result code exits. Valid - The result was returned to the server and was equal to the majority of results returned for the workunit. Rather, some factor not evident in the logs is used to determine which work unit is valid. Invalid - The result was returned to the server and was not found to be equal to the majority of results returned for the workunit. Perhaps if those caveats were to be added to the FAQ? Those of us with technical backgrounds...with decades and decades of reading logs to ascertain cause and the sequence of events...can be easily confused by a paradigm shift wherein the best outcome is indicated by the worst log. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The moment I opened this thread, I got such a big headache. My view got blurred and had a kind of nausea. lolll...I prefer to place the evidence out there and let someone with access ponder the situation until they go "Ohhh... Btw what is the question  !!!". Were it my "glass house", I would have simply said: "Somebody check to see how many times tasks have been sent out where the 'quorum' requirement doesn't mandate some number of identical results - e.g., three tasks sent out, of which at least two must have identical results in order to truly validate the work done - but instead has an effective 'quorum' of one (first come, first served?) even though multiple copies of the work unit are being sent out. But I'm...particular, which isn't always the case or even a requirement elsewhere. So I throw what I know out there, and if it doesn't stimulate any interest/ring any alarm bells, no skin off my nose. It isn't, again, my "glass house".In particular, focus on results wherein one of the involved BOINC clients used is not 6.10.58. I want to know how many times results with a log indicating no errors were rejected as invalid in favour of an error-filled result...and for all instances where that combination has occurred, I want to know why and I want at least 50% of the results re-validated in order to ensure that I am not basing future actions upon suspect input data. And I want to know why we are duplicating efforts by sending out tasks to two [3?, 4?.?.?.?] different clients if only one of them matters regardless of log contents." [Edit 1 times, last edit by Former Member at Apr 25, 2012 4:56:22 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Must have had some effect...the aforemention WU name - E207129_ 977_ C.26.C22H14N2SSi.01928398.3.set1d06_1 - has now disappeared from my results.
Is magic! Like the plot of a bad conspiracy theory movie. |
||
|
|
KWSN - A Shrubbery
Master Cruncher Joined: Jan 8, 2006 Post Count: 1585 Status: Offline |
Occam's razor. All results disappear within a day or two of going through validation unless they are purposely held by the staff. Beta is generally the only exception to this.
---------------------------------------- Distributed computing volunteer since September 27, 2000 |
||
|
|
Hypernova
Master Cruncher Audaces Fortuna Juvat ! Vaud - Switzerland Joined: Dec 16, 2008 Post Count: 1908 Status: Offline Project Badges:
|
The moment I opened this thread, I got such a big headache. My view got blurred and had a kind of nausea. lolll...I prefer to place the evidence out there and let someone with access ponder the situation until they go "Ohhh... Btw what is the question !!!". Were it my "glass house", I would have simply said: "Somebody check to see how many times tasks have been sent out where the 'quorum' requirement doesn't mandate some number of identical results - e.g., three tasks sent out, of which at least two must have identical results in order to truly validate the work done - but instead has an effective 'quorum' of one (first come, first served?) even though multiple copies of the work unit are being sent out. But I'm...particular, which isn't always the case or even a requirement elsewhere. So I throw what I know out there, and if it doesn't stimulate any interest/ring any alarm bells, no skin off my nose. It isn't, again, my "glass house".In particular, focus on results wherein one of the involved BOINC clients used is not 6.10.58. I want to know how many times results with a log indicating no errors were rejected as invalid in favour of an error-filled result...and for all instances where that combination has occurred, I want to know why and I want at least 50% of the results re-validated in order to ensure that I am not basing future actions upon suspect input data. And I want to know why we are duplicating efforts by sending out tasks to two [3?, 4?.?.?.?] different clients if only one of them matters regardless of log contents." No offense intended. Your rephrased question here above is very clear and that I can understand it in terms of efficiency and quality of the validated results.  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Occam's razor. All results disappear within a day or two of going through validation unless they are purposely held by the staff. Beta is generally the only exception to this. It is good to know that the results page is invalid after "a day or two" for end-user purposes (e.g., to monitor the performance of your systems and watch for potential trouble issues across the web when you're physically away) especially given that the FAQ page confuses the issue by insisting that results are held for four (4) days.Notably, Results are only listed until 4 days after validation and where applicable quorum is complete and or no more work needs to be send out to achieve validation. Given that the work unit in question wasn't completed by my system until 4/22/2012 at 17:34:14, I rather expected it to stick around at least until today. On top of which, my results page routinely has at least two weeks of results.I do hope that you'll forgive my curiosity; it appears to be a case of garbage in/garbage out. I interpreted the sequence of events based upon what WCG's FAQs and so forth say reality is, when in reality it turns out that reality is a variable. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
To close this issue with what I have learned: From the perspective of the end user, the result logs are irrelevant and the results page is largely irrelevant; the relevancy of the result itself is determined by the science project in question in a manner that is opaque to the end user.
To paraphrase William Cowper (1731-1800): |
||
|
|
|