There is no way to determine if the returned data is correct without
validation of some kind. There are two possible ways to do validation, and
it depends on the original problem. First is that the server can run a
reverse calculation very quickly for some problems. For example, finding
the factors of a large number is intensive, but getting from the factors
back to the original number is very fast. The other method is to validate
against another result from the same WU. The third is to just ignore
errors because they drop out of the statistics done later, but this does
not help with error detecting computers that have large numbers of
successfully completed yet invalid results.
In my opinion, we should be detecting both errors and invalid tasks, which
leads to doing both reward and punishment at both report time and
validation time. We just have to ensure that the punishment for an invalid
task is greater than the reward for a successful task (so that the net
result for a successful but invalid task is a reduced quota or
reputation).\
Yes, the validation can occur many weeks after the report, but typically it
occurs within a few days for most projects. While it is useful, it is also
required that some action be taken on the report.
jm7
Raistmer
<[email protected]
> To
Sent by: "Richard Haselgrove"
<boinc_dev-bounce <[email protected]>,
[email protected] "Jorden van der Elst"
u> <[email protected]>, "Josef W.
Segur" <[email protected]>
cc
05/26/2010 10:59 BOINC Developers Mailing List
AM <[email protected]>
Subject
Re: [boinc_dev] host punishment
mechanism revisited
> 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.
_______________________________________________
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.
