Wrong numbers in "max # of error/total/success tasks"
Message boards : Number crunching : Wrong numbers in "max # of error/total/success tasks"
Author | Message | |
---|---|---|
I have no problem in general with the numbers 0/1/1 in those fields of the WUs, only you should never resend a delayed WU to another cruncher if you won't accept 2 valids.
|
||
ID: 5056 | Rating: 0 | rate: / | ||
As you haven't changed the numbers, am I correct that you will never resend non-valid completed WUs ever?
|
||
ID: 5064 | Rating: 0 | rate: / | ||
I agree with Saenger...
|
||
ID: 5072 | Rating: 0 | rate: / | ||
As an initial answer to this problem just let me tell you that it was sending additional jobs of the same workunit because of a bug in the transitioner. We fixed this issue a while ago, but in the last relocation the transitioner was overwritten. Now it was restored and the maximum number of jobs shouldn't be a problem anymore. Regarding to the maximum number of success, it is correct, a better value is 2 and now it is changed.
|
||
ID: 5073 | Rating: 0 | rate: / | ||
As you haven't changed the numbers, am I correct that you will never resend non-valid completed WUs ever? Hi, I want to address the question "Does that mean you don't need all WUs crunched to achieve your result?" We consider any WU as an important WU however the WU is not relevant as a single result but as part of a larger set of results. We post-process the set of results and we identify tendencies. The more results we have, the larger is the probability that they converge toward a correct answer. In other words, we replaced redundancy (that resulted in wasted cycles) with a powerful post-processing analysis that allows us to identify outliers (possible results affected by errors) and convergent results (tentative answers). Michela ____________ If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'! |
||
ID: 5078 | Rating: 0 | rate: / | ||
As you haven't changed the numbers, am I correct that you will never resend non-valid completed WUs ever? Michela, some time ago, when I was first starting to crunch D@H WU, I was sent a large number of WU with a short deadline. Since D@H is not my only project, the work overload caused D@H to run in "High Priority" thus shutting down the other project. In order to reduce the work overload, I aborted about half of the D@H WU. Then I checked one of the aborted WU on the web site and saw the line. max # of error/total/success tasks 0, 1, 1 Since the abort was counted as an error, all of the aborted Work Units will never be sent out again. This may or may not be an issue, given your post-processing. Now, however, I see that the number of success tasks has been set to 2, but the error and total numbers are unchanged. max # of error/total/success tasks 0, 1, 2 It might make sense to change the counts to be 1 for errors, 1 or 2 for total, and 2 for success so that an abort will not prevent the WU from being reissued. D@H settings of errors 0, total 1, success 2 will cause the WU to be abandoned with one error or any 2 results. Again, maybe this is OK with your post-processing... ____________ |
||
ID: 5090 | Rating: 0 | rate: / | ||
Message boards : Number crunching : Wrong numbers in "max # of error/total/success tasks"
Database Error: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) { [0]=> array(7) { ["file"]=> string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc" ["line"]=> int(97) ["function"]=> string(8) "do_query" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#11 (2) { ["db_conn"]=> resource(78) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(51) "update DBNAME.thread set views=views+1 where id=434" } } [1]=> array(7) { ["file"]=> string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc" ["line"]=> int(60) ["function"]=> string(6) "update" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#11 (2) { ["db_conn"]=> resource(78) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(3) { [0]=> object(BoincThread)#3 (16) { ["id"]=> string(3) "434" ["forum"]=> string(1) "2" ["owner"]=> string(2) "79" ["status"]=> string(1) "0" ["title"]=> string(53) "Wrong numbers in "max # of error/total/success tasks"" ["timestamp"]=> string(10) "1245946787" ["views"]=> string(3) "154" ["replies"]=> string(1) "5" ["activity"]=> string(19) "1.1206908734979e-87" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1243932307" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } [1]=> &string(6) "thread" [2]=> &string(13) "views=views+1" } } [2]=> array(7) { ["file"]=> string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php" ["line"]=> int(184) ["function"]=> string(6) "update" ["class"]=> string(11) "BoincThread" ["object"]=> object(BoincThread)#3 (16) { ["id"]=> string(3) "434" ["forum"]=> string(1) "2" ["owner"]=> string(2) "79" ["status"]=> string(1) "0" ["title"]=> string(53) "Wrong numbers in "max # of error/total/success tasks"" ["timestamp"]=> string(10) "1245946787" ["views"]=> string(3) "154" ["replies"]=> string(1) "5" ["activity"]=> string(19) "1.1206908734979e-87" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1243932307" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(13) "views=views+1" } } }query: update docking.thread set views=views+1 where id=434