IMO it's not about credits (big or zero) at all, it;s about to prevent host to download excessive number of tasks that will be most probably just trashed. SETI's overflow -9 is hard case, cause "invalidness" of task will be detected much later. Task returned as "valid" one. Watching for execution time will not distinguish between "true" overflows and broken GPU results actually, sometimes broken GPU will return invalid overflow after ~20 seconds ov work, not immediately. But in any case, overflowed tasks return "-9" instead of zero, so can be easely distinguished from all others. IMO SETI could treat these tasks as "computational errors" in sense of quota limits and not await their validation. Surely it will negatively affect all hosts in case of very noisy data tape, but probability of getting let say 100 "true" overflows in row for any particular host could be evaluated by SETI's staff to see if it should be taken into account or broken GPU much more probably source of overflows.
----- Original Message ----- From: "Jorden van der Elst" <[email protected]> To: "Josef W. Segur" <[email protected]> Cc: "BOINC Developers Mailing List" <[email protected]> Sent: Wednesday, May 26, 2010 2:55 PM Subject: Re: [boinc_dev] host punishment mechanism revisited > On Wed, May 26, 2010 at 12:29 PM, Josef W. Segur <[email protected]> > wrote: >> As has been mentioned a few times, there's a fundamental difficulty >> in applying host punishment quickly because it can depend on when >> a result is validated. > > Not if there are strict(er) rules to what is "a valid result". Is a > valid result just those that are not returned immediately with an > error, or is it all work after validation? Is it strictly about the > work being done, or is it to safe-guard against "wrong-doings with > credit"? > > At this moment a valid result is work returned before the deadline and > without errors, but prior to validation. > > E.g. at this moment - taking Seti again as an example - there are > Linux computers out there that return valid results that show zero CPU > time, thus claim zero credit. If paired against another box claiming > zero credits... > > There are also all_platform computers out there that still run BOINC > 4.xx, which categorically claim zero credit. And usually everyone in > that group gets those zero credits, as the work is validated as being > correct. > > If it's strictly about work being returned immediately with an error, > then the present restrictions may be adequate. > If it's to safe-guard against zero CPU time claimers who apparently > (after validation) return good work, does there need to be something > else done? What? > If it's to safe-guard against zero credit claimers/zero credit > granters? The best solution is to get them to update to a newer > version, but how? > > > -- > -- Jord. > _______________________________________________ > 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.
