Improved work allocation.


log in

Advanced search

Questions and Answers : Wish list : Improved work allocation.

Author Message
Grant (SSSF)
Send message
Joined: 19 Aug 99
Posts: 5787
Credit: 57,856,121
RAC: 48,146
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.

John McLeod VII
Volunteer developer
Volunteer tester
Avatar
Send message
Joined: 15 Jul 99
Posts: 24321
Credit: 519,653
RAC: 31
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

Grant (SSSF)
Send message
Joined: 19 Aug 99
Posts: 5787
Credit: 57,856,121
RAC: 48,146
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.

Questions and Answers : Wish list : Improved work allocation.

Copyright © 2014 University of California