Resource sharing is something that actually CAN be done with immediate response. I cannot imagine any reason why it wouldn't be, but I can clearly see that it isn't.

The algorithms is anything but simple. BOINC is open source. You can always submit your simple fix for the developers to look at.

Edit
HINT: Starting point.
Separate the RS for CPU and GPU. Modify server and manager software to implement separate RS. Make sure that the new manager will work properly with projects running older server versions without split RS. Ensure that older version managers wont be broken by the split RS on the server.
Make sure everything works with a mix of projects with old and new software .

You are still expecting immediate response. It doesn't work that way. It can take weeks before RS finds a balance. It took me 6 months to balance my SETI and Milkyway project. There is always overshoot by one or the other project, but in the long term a balance is maintained. The trick was to make incremental changes. Next I will tackle Einstein which took a big jump ahead when SETI was misbehaving for almost a month.

BOINC Manager is the graphical user interface, that allows you to command and control the BOINC client. BOINC Manager on its own makes no command decisions.

But as you have been told many times now, your problem stems from elsewhere, from your demand to run a cache with 10 days worth of work, when Seti cannot fulfill that demand due to them having a 100 task limit in place. Aside from varying deadlines.

You can continue to post your complaint in all forums we have, but in the end it is you who has to change your settings, or your choice of projects. And else... there's always the source code, now also available at Github. Download, change to your heart's content, compile and run your own MOINC.

As far as I am aware, there is no functionality for an end user to accurately and reliably tell BOINC how to split our donated system resources.

All we can do is tell BOINC what projects we want do donate time to, and how we want our resources divided. After doing so, BOINC completely ignores our desires and spends all of it's time working on the project whose development team has been more aggressive about cheating the system.

If I say I want a resource share of 100 devoted to one project and a resource share of 5 devoted to another project, I couldn't care less what funny calculations are happening somewhere other than at my computer. My local machine is more than capable of tracking how much real processor time is spent on each project.

All resource share allocations should be performed on the client. Period. But for some strange reason they aren't.

Before some expert cruncher steps up and gives a thirty-step process on how you can modify this, and adjust that while restricting other things in order to maybe have a chance of BOINC doing what you have already told it to do... Once a person who is generous enough to devote cycles to BOINC projects has indicated what they want to contribute to by adjusting resource shares, that's it. Nothing else should be required. End.

This really needs to be fixed.

Your perception is incorect. A project may be able to jump the queue with short deadline forcing priority processing, but this doen't give more processing time to the project in the long term. Boinc just wont ask that project for more work until RS is met with other project.

There are another couple recent threads on this board about this issue. The figures that BOINC uses in the work fetch are REC numbers, not RAC numbers, assuming you are using a reasonably recent version of BOINC. If Asteroids is using credit inflation, they are, then the RAC numbers you see will be way out of line. This in addition to the new fetching can cause users to think BOINC is beserk. The new fetch will grab as much work as possible, until the buffer is full, from a SINGLE project. So if it attempts to get work from SETI and there isn't any -- AT THAT PRECISE MICROSECOND -- then it will go to Asteroids and gorge itself, no matter the relative work fractions.

As I pointed out on the SETI forum. Stick to a small cache, and leave BOINC to stabilize. Then you can make incremental changes to resource share until things reflect you're wishes. Don't forget that if you're using Credits as your benchmark then you have to take into account that some projects do pay out a lot more per computing time then others. GPU's crunching especially have a very large discrepancy between projects.

Stop trying to understand the work-sharing algorithm. I gave up a long time ago, when it was significantly changed after version 5.x or 6.x (I don't remember). There are plenty of detailed explanations floating around on this forum regarding the rationale behind the algorithm. I think it fails to satisfy the observer mainly because so many projects do a bad job of estimating their tasks' Time to Completion, especially when that results in a very short deadline and BOINC gets all panicky and urgent. To get the outcome you seek, you either have to micromanage BOINC constantly or leave it alone for a long period of time so it can "learn" how long the assortment of projects/tasks you have chosen actually perform on your machine.

and tell the projects that I want 10 days of data for each of them

The Cache settings are Global, setting a Cache setting of 10 days means 10 days overall, Not 10 days for Seti and 10 days for Asteroids.

Claggy

BOINC will do all work before the deadline, so you can only "hold back work" by suspending that work or suspending the project. The Einstein project being the backup project will fill the cache only when Seti is out of work, and because Einstein has a zero resource share, all work for it will be done immediately and in high priority. Even when Seti has work again, the Einstein work will be done first, because of the zero resource share.

BOINC already has something similar to what you want. If you want only project A tasks when project A has them and want project B tasks only when A doesn't have tasks then give A a resource share greater than 0 and give B a resource share of 0. If you're worried that both A and B might not have work simultaneously then give project C a share of 0 as well. It's not likely that all 3 would not have work at the same time.

Projects want their tasks returned in a reasonable amount of time so I highly doubt any project would agree to give you a deadline "far, far in the future" just because you're asking for a fill in task.

To me it seems the scheduler is complicated enough already and there's not much to be gained from your scheme compared to what we already have.