Suspended tasks are included in the buffering computation. This is a change from previous clients. You don't need to do the old trick as there is the new 'cache' (web device profile) / 'additional buffer' (Local client preferences). Set that option to e.g. 1.0 days and you should be okay again, BUT, it's dependent on the speed of the computer. If it takes a day to complete a job, it wont fetch more than what the cache was set for. AND, the buffering computation includes the time still to go on the jobs running.

|
If not mis-remembers, this particular change was done in v5.8.xx.

The main reason for this change is to stop client becoming hopelessly overcommitted and missing deadline of most of the work, something that often was the result then users suspended tasks to download more work.

If users wants more work, they should increase their cache-size instead. And, in cases like SIMAP that has only work a couple days/month, temporary suspending other projects will have the same effect, but you won't be overloaded with work in a single project, but it's still possible the sum of work across multiple projects is too high so starts missing deadlines...

Anyway, v5.10.xx blocks work-request to a project if project has:
1; Atleast one download has failed and shows "retrying in ... h/m/s".
2; If there's more than 2x #cpu's uploads in progress or queued.
3; If atleast one Task is suspended.
4; If set "no new work" (or project suspended).
5; If atleast one Task is in deadline-trouble. This Task shows as "Running, high priority" in Tasks-tab.

The last, #5, will be overridden if you've got an idle cpu, while the four other rules is in effect even if computer idle.

Some of the reasons for these rules:
#1 If you're having problems downloading one wu (or application), it's a good chance you'll have the same problem downloading another wu, since most likely it will come from same download-server. If problem is on clients end, it often needs manual fixing...
#2 In case computer crunches wu's faster than manages to upload them, continuing downloading more and more work will give larger and larger problems, and eventually leads to all work returned too late.
#3 Stop client becoming hopelessly overcommitted, and also less chance to overlook the suspended task that slowly passes deadline. Also makes it harder for users to "hand-pick" the "juicy, high-credit/hour" wu's, by suspending the "low-credit/hour"-wu's.
#4, Because asked to do so by user.
#5, To not make client becoming even more overcommitted.

All decreases the chance of client becoming overcommitted, while #1 and #2 will also decrease the load on project-servers in case the problem is on their end.

Ok, here is the results of my experimentation. I let one task get to 15 minutes-to-go and then suspended it. The other tasks in the queue completed and reported, but the client would not request more work. I increased the cache to 3 days from 1 day and it still did not request additional work.

This would appear to be caused by the logic in item #3 from Ingleside's list (block work-request to a project if project has at least one task suspended). It would appear that my initial observation ("It is acting as if I selected No New Tasks for the project") was correct. Ingleside's post indicates that it is an intended characteristic. (BTW, the previous version that I ran was 5.8.16)

To me, logic #3 appears to be redundant with #4. If I wanted to prevent the client from fetching new tasks I would have selected that. I don't think that suspending one task should have the effect of blocking all new tasks.

Looking at the time-to-completion would have been valid as Sekerob initially tried to explain. Ingleside is right; I was trying to cherry-pick WUs. I had several long running WUs in my queues when NRW came on-line and I wanted to manually give NRW priority. It is not my style to abort WUs, so I just wanted to put the others on ice for a few days. I don't think that there is anything wrong with that. I was at no risk of being over-committed. Why provide the manual controls if we are not permitted to exercise them?

I am not trying to blame or vent at any of you. If that is the current intended operation of BOINC, so be it. I just don't agree with it. Thank you for your responses. Unless anyone has anything else to add, we can consider this resolved.
Cheers