Not quite right, it only blocks work-request from a project as long as the project is in deadline-trouble.

If you've connected to multiple BOINC-projects, you'll normally have a full cache, even one of the projects is currently being blocked.


As for "screwy algorithm", if you're example running with a 4-day cache and each wu takes 5 hours, what is your situation when an unexpected outage starts?
1; You've got 96-100 hours cached.
2; The wu you're currently crunching, was downloaded 96-100 hours ago...

Meaning, if an unexpected outage lasts until your cache is out, 96-100 hours, your oldest unreported result is now... 196 hours old, over 8 days old...

If deadline is example 7 days, it means your oldest result is reported over 1 day after it's deadline is over...

Now, if it's the whole project going down, you still have a chance your too-late results is still useful and you'll get credit, but if it's more local problems like your ISP having problems, chances are the 1+ day of crunching on the 4-day outage was just wasted electricity...

Oh, and in some BOINC-projects like LHC@home and SETI@home, even if it is the whole project going down, chances are wu is already validated by the time your too-late results makes it in, and again you'll get zero credit...

Generally, if the point of the cache is to handle unexpected outages, it's a waste of time to set this cache larger than 1/2 the deadline. V5.8.xx just enforces this fact, but has added an extra 1-day safety. If not mistake, v5.10.xx also enforces this fact, but has removed the 1-day safety...

Planned outages would be different, but most outages is unplanned, so BOINC-client treating everything as unplanned shouldn't make a big difference.

A new work-scheduler was introduced in v5.8.xx, using:
Computational deadline = report deadline - (Work Buffer size + 1 day + "switch between projects every N hours")
A Task is in deadline trouble if Computational deadline < 0.9 * report deadline

Due to these formulas, the max usable cache-size in v5.8.xx if deadline is only 2 days is... 0.45 days...

For other deadlines, see Work Buffer

In v5.10.xx you've AFAIK still using the same formulas (I should really check this), but without the "1-day" safety, meaning max usable cache-size is around 0.9

So, upgrading to v5.10.13 or later should improve things, but it's possibly you'll still run out of work. Your options then is either to de-select FightAids@home until new application with long deadlines is released, or attach to one or more of the other BOINC-projects.

An auto-adjusting is undesirable, since same computer can be attached to one BOINC-project with 1-day deadline and another with 1 month deadline. Even 10 days-cache is much too large for the 1-day project, client will still try to keep 10 days cached in the other project.

Some projects has variable deadlines, or only for a short time like now in WCG.

Ingleside - That does make good sense. In my limited experience with WCG, most everything has had deadlines approxmately equal to each other. Thanks for shedding some light on the subject.

Sekerob - Thanks for the heads up on the version differences. Although I didn't post the screenie to brag, but it is nice to have someone notice. Dual Xeon E5345's. I was averaging around 40 completed units a day on this machine, but this queueing issue has dropped me to 30.

I de-selected FAAH from my BOINC profile a few days ago...problem solved! err, avoided!