What you describe is how things work currently; the work fetch policy treats downloading jobs as if they were downloaded. This prevents infinite work fetch, but as you point out it can lead to processor starvation. If BOINC is to be used for truly data-intensive problems we'll need to address this issue.
I can think of some ways to relax the policy, but they're a little tricky. If anyone has a good idea let me know. -- David Janus Kristensen wrote: > Hey all > > I'm forwarding a report concerning the client and possible issues with > lengthy or failing downloads. I haven't had the time to verify it so > just ignore it if this is not (or no longer is) the case. > > Situation: > 1) Client attached to multiple projects > 2) Cache set to X days of work > 3) A project releases workunits with downloads that take around X days > to get (slow, big or failing, the issue is naturally more pressing for > clients with smaller values of X.) > 4) Client is registered to some WUs and starts downloading - the > scheduling mechanism is satisfied > 5) Client eventually runs out of work and stalls until the download > completes or fails entirely. > > Problem: > The client isn't doing anything. CPU utilization is 0%. > > Expected behaviour: > The client would fetch and work on something else while completing the > lengthy download. > > Difficulties: > Detecting the situation and determining the course of action (finding > alternative work). > > > -- Janus > > > _______________________________________________ > 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.
