High flux projects such as CEP and HCMD2 are the reason. If you have 4 days in queue and suddenly a few jobs run 3 times longer, all the jobs in buffer start extrapolating that to themselves. I.e. I had flu jobs in the queue that run 5-6 hours, but after a few extended jobs, started showing 25 hours. It was enough to stop all work fetching for a few days until almost all was depleted and BOINC wised up and lowered the socalled rDCF (result Duration Correction Factor). In case of 7 days, there would thus have been way too much and a panic state [high priority] taking over.

Mind you, if you have a long series of 1 hour jobs and shorter for HCMD2 and suddenly the parent HCMD2 jobs in force come along that run 4 hours, similar happens. BOINC still think initially it can do them in 1 hour, load up and realize it got 4x more. The parents happens when a new batch is put in the feeders, so you'll always see the times saw toothing.

It's up to you to decide if you don't want those situations to develop or trust it will always come right. BOINC is as yet not enabled to handle different WCG projects with their own time projections. It's all 1 pot.

I explained why 4 days above. This value you'll also find in Help. It's a suggested maximum to prevent most excess buffering when work suddenly gets longer.

Appart for estimates being wrong, the main reason for the FAQ introduced the "4 days max" is due to http://www.boinc-wiki.info/Work_Buffer#Recomm...or_Single_Project_Systems that shows that with WCG's normal 10-days deadline, any cache-settings larger than 4.24 days actually gave less cached work in BOINC-v5.8.xx.

Later BOINC-clients introduced the "Maintain enough work for an additional N days"-cache-setting, and as long as "Computer is connected to the Internet about every N days" is small, you'll not have the same client-limitations for large cache.

Still, the main cache-rules are, if cache-size is due to:
A: Planned outages, like if you know computer won't have a network-connection for a week, use as large cache-setting as needed to cover the outage, but remember the 10-day deadline on most WCG-work, or currently 14 days if you only runs CMD2.
B: Unplanned outages, like server unexpectedly going down, or your network-connection unexpectedly going-down or something, it's a waste of time to cache more than "normal deadline / 2". For WCG this means absolute max 5 days for this group, with recommended 4 days.

Well, I pointed to why the WCG-FAQ recommended max 4, it's not my fault the WCG-FAQ doesn't seem to have been updated since v5.8.xx in this regard...

As for users cache-size, I'm not aware of there being more than two major groups, the group that "need large cache since computer offline for N days", and the group that "needs" a large cache "to handle outages"...

For the 1st. group, they'll likely manually re-enable network-connection, so can also handle any excess cached wu's at the same time, and most would likely set a little excess cache just to be on the safe side doesn't run-out much too early. This is a disadvantage to WCG, but isn't really much to do with, since even with "perfect" estimates, there's still the ocassional wu that terminates early...

For the 2nd. group, they're most likely permanently connected, so most normal fluctuations will fit within the "deadline / 2"-rule with the extra "safety-margin" gave it. But granted, the CMD2-estimates especially at the start was so far from the truth, that even with a 1-day cache-setting you risked being overcommitted.


BTW, if you're really going to take into account the wrong-estimation for the group that "needs" a large cache-size, you'll need to set a shorter cache than 4 days... If example estimates is 1/2 of reality, the cache-size should never be over 2.5 days with a 10-days deadline.