Over the last few days, i've run out of CPU work several times, while still having a good sized cache of GPU work.

Over the last week, the Scheduler was responding to work requests with "Project has no tasks available" most of the time, with the occasional "Scheduler timed out" error. Very occasionally it would allocate work, but generally only a couple of WUs at a time.

The Scheduler now appears to be delivering work with most requests, however because the cache had become so run down from the previous weeks' lack of work i ended up running out of CPU work, because the Scheduler kept supplying work to my GPU (fastest porocessor) even though it still had several days worth of work to process.

Instead of making the Scheduler more complicated it would be good if the client could make more intelligent requests for work, keeping in mind the Schedulers behaviour of supplying work to the fastest processor at the expense of the slower- regardless of how much work each may presently have.


eg- if a system has a 5 day cache setting, and it requests more work the request should be made based on each resources needs.
If the GPU has 4 days of work left, and the CPU only 2, then it should request only CPU work untill both have similar amounts left/similar amount to fill.**
If the amount of work required is similar, then request for both. The Scheduler being what it is will most likely only supply work the the faster processing resource. On the next request (depending on how fast work is being processed) the work required to fill the slower processing resource should be significantly more than that required for the faster- so work only for the slower should be requested.

** I'd keep the present backoffs & resets for missed work requests as they are. That way, if a request for work is missed on the slower resource, at least the faster one will still be able to maintain it's cache.
Once the backoff has been reset, the difference between the faster & slower processing resource will be that much greater, so once again it should request work only for the slower resource.

---

Grant
Darwin NT

Over the last few days, i've run out of CPU work several times, while still having a good sized cache of GPU work.

Over the last week, the Scheduler was responding to work requests with "Project has no tasks available" most of the time, with the occasional "Scheduler timed out" error. Very occasionally it would allocate work, but generally only a couple of WUs at a time.

The Scheduler now appears to be delivering work with most requests, however because the cache had become so run down from the previous weeks' lack of work i ended up running out of CPU work, because the Scheduler kept supplying work to my GPU (fastest porocessor) even though it still had several days worth of work to process.

Instead of making the Scheduler more complicated it would be good if the client could make more intelligent requests for work, keeping in mind the Schedulers behaviour of supplying work to the fastest processor at the expense of the slower- regardless of how much work each may presently have.


eg- if a system has a 5 day cache setting, and it requests more work the request should be made based on each resources needs.
If the GPU has 4 days of work left, and the CPU only 2, then it should request only CPU work untill both have similar amounts left/similar amount to fill.**
If the amount of work required is similar, then request for both. The Scheduler being what it is will most likely only supply work the the faster processing resource. On the next request (depending on how fast work is being processed) the work required to fill the slower processing resource should be significantly more than that required for the faster- so work only for the slower should be requested.

** I'd keep the present backoffs & resets for missed work requests as they are. That way, if a request for work is missed on the slower resource, at least the faster one will still be able to maintain it's cache.
Once the backoff has been reset, the difference between the faster & slower processing resource will be that much greater, so once again it should request work only for the slower resource.

This has already been noted. I believe a fix is in the works.

---

BOINC WIKI

This has already been noted. I believe a fix is in the works.

Thanks for the update, good to hear.

---

Grant
Darwin NT