cleanenergy: "You can select the number of CEP2 wus you want to crunch at a time by adjusting the value in ‘Number of workunits per host for The Clean Energy Project - Phase 2?’ (no complicated micro-management necessary)" ...
Thanks, but this is not the same as the no of CEP2 WUs to run simultaneously. This sets the total no of CEP2 WUs sent out but not yet returned & reported to the WCG server. I don't think the server cares what you are doing with the the WUs at a given moment.
Ballpark calculation for this CEP2 WUs setting (C):
s = no of Simultaneous CEP2 WUs to run
D = no of CEP2 WUs processed per Day per CPU core
Q = "Additional work buffer ... (days)" (Queue) setting in BOINC >> Advanced >> Preferences
C = s x D x Q
Without active management, the actual no of CEP2 WUs that run simultaneously will vary because the spacing of the CEP2s in the cache and the runtimes of these and WUs from other projects will vary. I have FAAH in some profiles, and FAAH runtimes are currently varying by over 2:1, and active queue management is needed to keep 's' constant.

Behaviour will be better if cache length is kept short so that a C setting of (2 x s) or (3 x s) can be used. However, some of us are old enough to remember the Great Boulder Colorado Christmas Blizzard way back in '06, when present Harvard scientists were nothing more than glints in their daddies' eyes. A WCG server in Boulder crashed near the start of the holiday period, people were on leave, and no-one could get access to the hardware anyway, because of the snow & ice. The server was down for about 4-5 days. Some of us like to run long-ish caches. 3 days is reported to be standard at XS.

lol...so Harvard's got a bunch of these running around:



...or did you mean 1906?

@SMTB1963 & Rickjb: Well, we essentially all look like this - LOL. Theoreticians in particular run around all day with an overfull beaker of CuSO4 solution, gigantic goggles, and an XXL sized labcoat. And yes, some of us could even already walk in 2006 (although that particular skill tends to get lost by spending too much time on the computer).

Thanks, uplinger, but as I pointed out, the WCG servers have frequent outages and with a work cache setting of only 0.01 days, I would often run out of work. About 10 hours ago, the WCG WU despatching server went out of action, complaining "can't attach shared memory" and I'd have run out of work.
The availability of DDDT2 WUs is currently very low, eg zero. I tried getting some exclusively only yesterday & failed to get any. Crunching only 1 CEP2 on a quad leaving 3 empty cores would be a 75% processing-time loss.
DDDT2 performs heavy disc I/O and in the past has caused one of my machines to lock up so that WCG programs stop for 30+ seconds and BOINC kills them. CEP2 is also doing this. Running the 2 projects together would not be a good idea. See also Re: work units not finishing , BOINC Agent Support > exited with zero st...o 'finished' file , Beta Test Support Forum > Re: BETA Clean ...ject phase 2 version 6.35 , My thread @ XS > WCG - WCG tasks die &quot...;finished' file"
Setting the number of outstanding CEP2 WUs to 1 almost guarantees that I receive no CEP2 work at all because WCG's bandwidth tests think that my connection is too slow, even though it can upload at around 100kBps and download at 10-20 times that.

I currently run DDDT2 exclusively with a cache of 0.4 days (soon to switch back to CEP2). Sometimes I go for hours without picking up any new WUs and this assures that I can keep crunching during those times. It certainly helped this morning with the outage.