Thanks SekeRob, I was tired of micromanaging my little quad which can't handle more than one CEP2 concurrently, so this was perfect news for me :)
Actually I went as far as bringing up a virtual linux just to run one also, so I can have 2 concurrent as long as it's not 2 windows concurrent. The efficiency is so poor in both cases that I net maybe a cpu day/day, but that's better than it was managing before.

Starting a CEP2 (windows) job still freezes the box for a minute while the disk pegs, and forces a restart on remaining boinc tasks which is annoying, but after playing with VM and memory and disk settings ad nauseum I gave up and just live with it. This project is close to my heart, otherwise it would be too annoying to run.

Anyway your news and clear explanation was very helpful so thanks.

Well, there is no golden bullet in terms of operating systems - different people have different demands. That's why CEP is provided for all the major operating systems.

CEP2 and app_config.xml: WCG website is broken!!

I am running a machine with max_concurrent for CEP2 = 3 (of 8 threads), and 1 other project selected (FAAH), with Minimum work buffer = 1.15 and Max additional work buffer = 0.70.
If I set the Number of workunits per host for the CEP Phase 2 in its Device Profile to the max exact number in the dropdown list (16), the pool of Ready-to-Start CEP2 WUs in the next-to-run part of the buffer sometimes disappears, and the number of CEP2 WUs that are running drops below my specified 3. At least the vacated threads run extra FAAH WUs.

Today I tried setting Number of workunits per host for the CEP Phase 2 = Unlimited. Since the change, the client has received 13 CEP2 WUs and 7 FAAH WUs. Since CEP2 WUs take about 5-7 hrs and FAAH take about 3-5 hrs, and less than 50% of the cores are assigned to CEP2, the machine will gobble up all of the FAAH WUs, and then 5 CPU threads will sit idle while the excess CEP2 WUs are crunched 3 at a time, until the work cache is reduced anough to allow downloading more WUs.

I don't really want to reduce the work cache, due to the occasional major WCG server outages. Yes, they've fixed all the computing problems, but hey I've heard that before. Then there are the sabotage attempts carried on by the North American climate. Yes, you passed through Sandy and the recent ice storm OK, but what about Boulder CO at Christmas several years back?

Please provide a way of increasing the maximum exact setting for Number of workunits per host for the CEP Phase 2, either by lengthening the drop-down list or by allowing us to simply type in the number.
==================

@[B.S] sTrey and others experiencing problems with systems freezing at CEP2 startup:

You can reduce this effect with a bit of micro-management, if you are at the machine when the CEP2 WUs first start. The trick is to force the next CEP2 WU to run for just a few seconds - say 5 - then suspend it and run a non-CEP2 WU or another CEP2 WU that has passed its initial startup phase. After a short while - say 20 sec, or after the HDD activity LED goes off - you can run the new CEP2 WU some more. Pausing your new CEP2 WU like this allows the HDD to catch up. You may have to repeat this cycle another time or 2. More precise time estimates depend on the speed of your CPU and disc system. LAIM must be ON of course.

This sounds onerous, but with app_config.xml limiting the max_concurrent for CEP2, you can pre-run as many CEP2 WUs as you like, subject to the amount of RAM and disc space available.

I have found the app_config file to be very useful for this project as well. This sure beats only a few in the cue at a time. I am trying to get 16 at a time an run between 2 and 4 on a machine with the rest being filled with additional work from other projects. This allows me to get hcc gpu work and fill in extra slots on the 12 core. I am trying to run a min work buffer of 1.45 an a max additional work buffer of 1.5 days set at the client preferences. I would like to see the WCG website updated so these settings don't need to be set at the client. The worst part for me has been updating linux clients without creating new client ID's all the time.

There was an inbalance in DSFL which was causing it to send out more than other projects. We have readjusted the weights on the feeder to help resolve this issue.

Thanks,
-Uplinger