> Every one of these is initially reported as a "success", with exit status > 0. If any language translation uses the same word for 'valid' and > 'success', it should be corrected - provided two suitably distinct words > can be found in that language, of course.
OK, you right. So I see big problem in next task: how to determine possible data corruption in "successfully" returned result _BEFORE_ standart validation procedure (that can be done much later). Rigorously correct answer is "no way" IMO, but BOINC could make some assumption about probable task outcome to prematurely [unish host with suspicious results. If host just crashes tasks it will be immediately detected, but such silen failures of CUDA devices are the biggest evil for now IMO in part of excessive task trashing. Task will not immediately re-routed to next host as in VLARkill case, it will sit in database until validation time... > These '-9' overflow codes that we introverted SETI-zens are so fond of > bandying about are not BOINC exit codes. They are buried deep in the > ![CDATA[ xml structure carried in stderr_out. BOINC has no business poking > its nose in there - that would be akin to the postal service steaming open > your mail to see if you'd enclosed a winning lottery ticket. Yes, my fault, if something other zero would be returned it would be plain "computational error" outcome and BOINC could deal with it w/o any additional logic needed. > data count in the uploaded science result file. In any event, it's pretty > clear that it is taken from the canonical result (validated tasks only), > so it doesn't help us with this BOINC problem. Yes, then suspiciously short computational times solely attribute of such tasks BOINC can see. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
