It's true that the resend mechanism skips checks for whether the task
is feasible, and doesn't recalculate deadline. It was designed to take
effect at the very next Scheduler request. So those resent tasks
which are already approaching deadline will be a transitional problem
on some hosts. I agree that some users who have checked have found more
than 1000, but IIRC those were on very productive hosts which can do
1000 tasks within a few days. Still, it would be good if there were a
practical way to only resend those which won't greatly exceed the
amount of work time being requested, and transition the others to the
"Abandoned" state which is the replacement for "Client detached".
I don't see an easy way of doing that, though maybe David will. If not,
users may need to abort some or let the client do so for tasks which
don't start before deadline. I think that's better than having them all
expire without actually ever reaching the host.
--
Joe
On 11 Aug 2010 at 23:43, Richard wrote:
> 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.
_______________________________________________
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.
