The cache is a time period. Your app_config has no influence at all to what tasks from which project you get.
12 ARP1, 8 MCM1 and 8 OPN1. I suppose this is your setting in your profile.
Since ARP1 is more or less intermittent, I decided to run 2 or 3 BOINC clients on 1 machine. One client has a dedicated profile for ARP1 only. The other client(s) are running MCM1 or another project (DENIS or LHC)
When it's ARP1-time, I have to suspend the projects on the other clients or reduce the number of threads, depending on how many ARP's are running.

BOINC always have had problems with estimating needed work cache when there is a great variety in runtime duration of tasks.
When you have had a lot of MCM's in a row, BOINC will underestimate a ARP-task.
Your machine could be overloaded with ARPs when they suddenly pop up, because of this underestimation.
In your case limited by your project preferences of 12 ARP1s.
The opposite is also true. After several ARPs, the 'runtime duration for MCM will be over-estimated.

You could examine BOINC's work fetch policy by setting the <work_fetch_debug> flag to 1 in cc_config.xml

I think it is probably both. The project don't seem to be ready for the results yet and WCG said that they now had a bit more space to store results, but I suspect that is limited. I would prefer that they concentrated on the early generations as a priority.

There also seems to be capacity problem at WCG which is causing the http problems on upload/download.

Mike

Sunday Report

There have been no extremes or accelerated units validated this week.

5,931 units have been validated this week

Assuming that a full generation 182 will be the last, there are 1,640,486 units still outstanding. I will re-start my forecasting once output stabilises.

The definition of accelerated and extreme remained generations133 & 128, respectively but normals now include generation 144.

There are still 35 Extremes and 57 Accelerated units listed as none have moved. The numbers in their generations remain 2,200 & 3841.

Mike