Throwing the Gauntlet, would WCG not see same machine, same IP internal/external and get the heck confused? Hmmm, maybe it still works going through a full attach procedure with a clean copy so it creates a new ID. Not for the weak at heart and cant see this to be the object, to circumvent single device allocations. Of course as noted, the device instance needs setting to 1 core or you'd be running multiple sciences per core... very slow... hmmm, someone might get ideas v.v. Beta. Can't see this flying for long.

Changing the server code is better than running multiple instances. I'll wait on uplinger's update on CEP2 only.

Looking at the projectoptions it seems impossible to do but our goal is simple and it goes like this:

if (apps_selected > 1) and (app_id = 26)
do sched_limiter
end if

Lets all be clear here. The change is not to address the "ERRORS" but the inefficiency of the app due to heavy I/O.

I wonder whether the issue might almost solve itself if/when the Windows app goes live.

Before the change to 1 CEP2 WU per client, Linux users who wanted to run a mix of WCG projects so as to have just 1 CEP2 WU run at a time, had to do a lot of babysitting because they tended to get mostly CEP2 regardless of what they put in the mix. No doubt that was because the ratio of available CEP2 WUS to clients that could run them was high.

Maybe once this project opens up to Windows, there will be so many more boxes running CEP2 that mixtures will work out better for those who want to limit CEP2. Then the 1-per-client restriction perhaps will be lifted. That would be great for folks whose machines run multiple CEP2s well.

I tend to agree that this is a factor. They had problems in CEP and during the partial launchof CEP2. I just can't see Harvard wanting more work faster just right now.

@Evilkats: You are too funny. You want to back up that statement with a side bet? CEP2 will get done.