Subject says it all. I'd like to see cache size (Connect to Network Every x Days) become a project specific, rather than global setting. This would be useful to avoid going into EDF for projects with a lower resource share.

Actually, a better fix for the EDF problem is already "on the list" - to take into account the resource share when doing work fetch. Then when it gets "x" days work, it'll get 90% from your 90% project and 10% from your 10% project.

I'd still like to be able to set the cache per project though... it's just that that is a much "larger" change to the code, so it's unlikely we'll see it soon.

---

Actually, a better fix for the EDF problem is already "on the list" - to take into account the resource share when doing work fetch. Then when it gets "x" days work, it'll get 90% from your 90% project and 10% from your 10% project.

That's some help, certainly.

I'd still like to be able to set the cache per project though... it's just that that is a much "larger" change to the code, so it's unlikely we'll see it soon.

Of course, there's another reasonably good reason for it, as different projects have different urgency, and will vary widely on their return requirements. If the BOINC client doesn't also take that into account, we'll still have similar problems. If my system's fetching 10% of the work from a project with 10 times the deadline time ... well ...

I'm sorry but this will not be happening. The queue size setting is more likely to disappear entirely than to be made project specific.

As mentioned in other posts the client should become more inteligent about how much work it gets from a specific project (no more 5 days of work from a 1% project).

---

BOINC WIKI

BOINCing since 2002/12/8

I'm sorry but this will not be happening. The queue size setting is more likely to disappear entirely than to be made project specific.

It seems like that would only discourage participation in multiple projects by those who have a particular project of primary interest, but if a decision's been made (shrug).

I'm sorry but this will not be happening. The queue size setting is more likely to disappear entirely than to be made project specific.

It seems like that would only discourage participation in multiple projects by those who have a particular project of primary interest, but if a decision's been made (shrug).

I use Backup projects for projects that I am not real interested in. I have not seen work for some of them since july when there were not problems of some kind.

---

BOINC WIKI

BOINCing since 2002/12/8

Maybe they need an option that says, "get one WU" of work from project zzz when there is no work from projects xxx and yyy and I am idle. And don't mess with debits and such while it is processed.

That way, when the project(s) you are interested in 100% of the time are down, you have a backup that BOINC switches to one WU at a time until your favored Primary project(s) are back online with work. It gets to finish in rotation and results sent back. Then back to what you want.

This could be setup as an additional or Secondary project list. Items in the Secondary project list would be tried in sequence looking for a single WU to process because the Primary projects are all down or out of work, and all Ready to run WU's have been finished. You would have to have the ability to move Secondary projects up and down in the Secondary stack, so that you can adjust your preferences for backup. You would only want to put projects in the Secondary list if they have relativly short or quick WU.

The big change here is the "get one WU" request instead of the get ####seconds of work request. The "get one WU" request can and should ignore all of the reporting and queue size calculations as it is just a way to get a machine out of an idle state. As long as the system is idle, a "get one WU" should work for any project. By not setting up a Primary project, you would be in effect telling BOINC to work like the old Seti client did. Get one, crunch one, send one back, repeat. With the advantage there is now a stack of projects to fall back on if the first in the list is not available for some reason. Minor problem for Dial-up users as there is no queue.