Improved work allocation.

Questions and Answers : Wish list : Improved work allocation.

To post messages, you must log in.

AuthorMessage
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 7475
Credit: 90,979,437
RAC: 45,930
Australia
Message 1289037 - Posted: 28 Sep 2012, 21:15:07 UTC
Last modified: 28 Sep 2012, 21:16:09 UTC

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

ID: 1289037 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 754,585
RAC: 140
United States
Message 1289104 - Posted: 29 Sep 2012, 0:40:32 UTC - in response to Message 1289037.

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

ID: 1289104 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 7475
Credit: 90,979,437
RAC: 45,930
Australia
Message 1289536 - Posted: 29 Sep 2012, 23:33:40 UTC - in response to Message 1289104.

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

Thanks for the update, good to hear.

Grant
Darwin NT

ID: 1289536 · Report as offensive

Questions and Answers : Wish list : Improved work allocation.


 
©2016 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.