You might want to think about transitional arrangements for this - there have been reports of quite high numbers of lost results at SETI recently (up to 1,000 or more per host, IIRC - can't check at the moment, as the message boards are down). Maybe start with 'lost tasks less than a week old' (or 'more than five weeks old'), and ramp it gradually to unrestricted?
----- Original Message ----- From: "David Anderson" <[email protected]> To: <[email protected]> Sent: Wednesday, August 11, 2010 11:04 PM Subject: Re: [boinc_dev] Lost tasks >I checked in the server change > (if a request reports already-reported results, > always resend lost results). > > This will make its way into s...@home in a week or two. > > -- David > > On 11-Aug-2010 10:37 AM, Josef W. Segur wrote: >> Indeed, that would be a good client feature, but should also be applied >> ONLY when the failed request asked for work. I believe most such failed >> requests producing lost tasks actually get an HTTP error 500 rather than >> a timeout, perhaps that could also be considered. >> >> With the delays involved in getting client changes adopted, which may be >> even longer for 6.12.x than earlier series because so many users dislike >> the Manager changes, I hope the simpler and quicker server-side change >> using detection in sched_result.cpp will also be implemented. It should >> usually be redundant information to the client change if both are >> implemented, but reported results are handled before the work request so >> there need be no difficulty there. > _______________________________________________ > 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.
