I have three varying resource share values:

SETI@home (main) - 1800
SETI@home (Beta) - 100
other BOINC app - 100

It seems like my actual resource utilization is more like this
SETI@home (BETA) - 90% - CPU tasks with Feb 17th deadline (only 8 tasks)
SETI@home (main) - 5% - CPU tasks with deadlines ranging from Feb 26 & 27, through March 10 - March 20 (many dozens of tasks)

So my SETI@home main tasks get no processor time now, for some reason, even though I have a backlog of tasks.

Perhaps I misunderstand the concept, but I'd expect SETI@home (main) to get the majority of the CPUs if it has workunits to process, given the resource share.

if you don't continously run beta, or only recently added beta, then it will try to 'catch up' with the work done by other projetcs, therefore running far more than the resource share would suggest.

If you want to get to the depth of it you need to enable the work_fetch_debug log flag in cc_config and log one cycle (one every minute or so)
You can post it and I'll explain the numbers.
you can also look at cpu_sched_debug (careful lots of output best to only log a cycle or two before turning off again) and sched_op_debug

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

It is based on a long term average, not a short term "snap-shot". Thus one might get a slug of data from one project with nothing at all from the others, eventually over time things even themselves out (but what the basis for the non-time axis is remains a mystery....)

You can add a line to cc_config.xml to decrease the average of the resource share counter.

<cc_config>
<options>
<rec_half_life_days>0.25</rec_half_life_days>
</options>
</cc_config>

I think default is 8 so by putting this line you change the counter with 32X increase in resource share calcuations made by boinc.

Anyone here is free(please) to say my numbers are wrong here.
I only changed the number to test and i haven't come to any conclusion on exactly how it works. Just that it does so. :)

The default is 10 days, but near enough.

You can watch the effect over time, and learn to spot when different projects reach the level of "next to request" (and how much they'll ask for), by setting the <work_fetch_debug> Event Log flag.

You'll also see why certain projects aren't requesting work there, and when the second or third in line is going to fetch instead.