I am running five projects. I have one project that has a limited flow of work units these days, and I have set this project to have a resource share of 1,000,000.

One of the other projects has large numbers of work for a week or two, then drops to no work, then after a few days, it goes back to having a large amount of work available. I have set the resource share on this project to zero.

The remaining three projects seem to have work on a consistent basis, and I have also set the resource share on these projects to zero.

What seems to be happening is this.

When the project with the 1,000,000 resource share runs out of work, BOINC picks up work from the other projects as it should. What I see is that if there is no work available from the project with 1,000,000 resource share for more than a few hours, the projects with 0 resource share seem to essentially take over running work even though work becomes available for the project with the 1,000,000 resource share. Sometimes, work is available for the 1,000,000 resource share project, but BOINC will continue to get work from the 0 resource share projects and miss the work from the 1,000,000 resource share project.

Essentially, I have to set the 0 resource share projects to not get work, suspend all work on those projects, and then request an update for the 1,000,000 resource share project to force it to get work.

I am wondering if this is expected behavior. To me, it seems that BOINC should check at some regular interval for work from projects, however, it seems that the time between checks doubles at every check if no work is available, and thus checks for work are separated by progressively longer intervals and become longer than what seems reasonable to me, at least. If this is standard behavior, it seems that this must be happening to others, too.

Thanks.

Resource share is based on a long-term work share, not a short term one - I think the time is weeks/months rather than days.
Also some project are not very good at sending out "sensible" amounts of work, in that they will only send out huge mountains rather than the handful that they "should".

Resource share is based on a long-term work share, not a short term one - I think the time is weeks/months rather than days.
Also some project are not very good at sending out "sensible" amounts of work, in that they will only send out huge mountains rather than the handful that they "should".

To amplify that statement: projects never 'send' work, projects respond to 'requests for work'. The BOINC client on your machine requests enough work to keep it busy for a certain number of seconds (based on your cache settings and usage history), and it's the job of the server to supply that amount of work.

Unfortunately, the server's estimate of how many tasks are needed to keep you busy for the given number of seconds can be, ahem, over-enthusiastic. This is particularly a problem for newly attached computers, and for computers which aren't available for BOINC to use for very many hours each day. BOINC - the project server, in this case - will eventually learn how much work to send in response to your requests, but by then you may have a minor case of indigestion.

The best advice when attaching to a project for the first time is to keep your cache settings modest until the learning period is over.

The request for more work for the 1mil share project could be in the state of project back off where there could be hours between requests for more work. Not sure if its a default BM thing or a response from the server to BM but I've seen it happen when a project runs out of work. Is the 1mil share project in that state while the 0 share projects keep getting work?

Thanks for all the replies, and my apologies for the late response.

The back-off time is at the nature of my question. When a request fails, the client backs off for a period of time. At each unsuccessful request, the back-off time increases such that it could easily reach 24-hours very quickly. I am not sure how the back-off time increases, but it seems geometric in nature, which, to me, seems overkill.

It would be great to be able to configure the back off time in some fashion so that back off times do not become inordinately large. I think those who provide computing power to specific projects may be better able to estimate necessary back off times should they choose to do so. For some projects a geometric progression of back-off time might well be appropriate, however, for other projects it might not be.

Thanks again!

---