I've recently ran into a very very old problem (which I deemed long solved) :

After running a Project mix of SIMAP (CPU only) and Collatz (GPU only), I added another CPU Project (Collatz).

What happened then, was that the freshly added Project basically runs exclusively (since 2 weeks now).
The only times BOINC 7.2.42 (both Windows and Linux) will allow SIMAP to run is when some of its WorkUnits eventually run into Deadline issues - all despite only 0.5 days Cache is used.

So far, only a much older BOINC installation (Linux 6.10.17) reverted to the correct sharing after a few days, now running a perfectly shared 50:50 amongst the two CPU projects.

The 7.2.42 installations, however, absolutely refuse to do so. Only when reducing the Resource share from its default 100 to i.e. 25 can I achive that at least some sharing takes place (still about 3:1 for Constellation).

So the big question is :
Why is it that BOINC 7.2.42 persistently and apparently ignores all rules for fair resource sharing amongst projects?

The way it is now, running multiple projects would seem to require quite significant manual intervention.
IMHO something is wrong with the resource sharing in the current BOINC release.

(although I can't pinpoint it, the behaviour reminds me of a very old Long Term Debt problem, where suspended or "no new work" projects erroneously accumulated massive amounts of debt, making the sharing formula inherently unstable and eventually causing BOINC even to go defunc by refusing to download new work)

---

This is a known and anticipated problem with the revised scheduling mechanism - see the notes at the very end of http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen.

The way to test whether this is indeed the cause of the particular problem you're seeing would be to enable <work_fetch_debug> in cc_config.xml, and observe the movement in the REC and prio values - are they (slowly) converging between the projects concerned? If so, BOINC will eventually return to the old behaviour by itself. But that's hard work, and causes much eyestrain....

Another useful option from cc_config.xml is

<rec_half_life_days>X</rec_half_life_days>
A project's scheduling priority is determined by its estimated credit in the last X days. Default is 10; set it larger if you run long high-priority jobs.

I personally find the default 10 days to be too high, with the effects you describe: I set it to 1 on my own hosts a long time ago.

Ah, thanks for the reply...

That explains alot - and since the project in question has a quorum of 3 and not a hughe userbase, it takes significantly longer to convert its tidal wave of pending credits into granted credits.
That likely aggravates the problem additionally.

The converging is taking place now, so I think I'm getting pretty close to see them run alongside "nice" to each other again soon.

I'll modify that 10 days that you mentioned to a smaller value, that should do the trick :)

---