Just downloaded the new version to specifically test the app_info.xml and see if I could get the system to not allow more of 1 CEP2 [one of those IO intense]. Here's the sample content:

The client was restarted with app_config.xml in the project folder before the first CEP2 job was pulled. When the 2nd CEP2 was pulled and manually started [against expectation it did] copied the config file to the main data_dir and restarted client again. 2 CEP2 kept running.

No matter, the object is to stop more than N to run concurrent, not to control how many are fetched. Can't see the relevance of how many there are in the buffer, the whole purpose WCG asked for this feature to be added, so volunteers don't have to cumbersomely control how many heavy duty to set the device profile to as maximum to send. Anyway, it's not working for me, and looking for any reports that show it does, or hints as to what may be wrong with the file format/placement, or also possible, it's not yet enabled, of course GFB, there's a bug.

My expectation was that the 2nd CEP2 job would be skipped, to start the next after in line [per FIFO]. It did not.
____________
Coelum Non Animum Mutant, Qui Trans Mare Currunt

A user at WCG pointed out that the wiki from which I copied the template has a closing tag error, a missing s in </gpu_versions>. He's got it to work as expected, to the point that if max per setting is running and no other is buffered, threads will go idle. In his example had 2 SIMAP running, 4 CEP2 buffered, and app_config set to allow only 1 CEP2 to run at a time. His quad had 1 idle core.

edit: OK, to confirm, it was the missing s in the closing tag. Current setting of max 1 and no more will start.
____________
Coelum Non Animum Mutant, Qui Trans Mare Currunt

Just a quick question on this. In the doco it mentions the tags needed, are they all required? Are the <gpu_versions> tags required?
____________
MarkJ

A user at WCG pointed out that the wiki from which I copied the template has a closing tag error, a missing s in </gpu_versions>. He's got it to work as expected, to the point that if max per setting is running and no other is buffered, threads will go idle. In his example had 2 SIMAP running, 4 CEP2 buffered, and app_config set to allow only 1 CEP2 to run at a time. His quad had 1 idle core.

edit: OK, to confirm, it was the missing s in the closing tag. Current setting of max 1 and no more will start.

Well, on documentation, apparently we're not to use that one, but the 'official' one at http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration .. yeah, I don't get it either. ;-)

1 Configuration file
1.1 Logging flags
1.2 Options
2 Command-line options
3 Environment variables
4 Application configuration

I've been playing around with this feature, and it seems to be very useful in two quite different forms.

1) For CPU-only apps.

<app_config>
<app>name</app>
<max_instances>N</max_instances>
</app>
</app_config>

<app_config>
<app>name</app>
<gpu_versions>
<gpu_usage>.xx</gpu_usage>
<cpu_usage>.y</cpu_usage>
</gpu_versions>
</app>
</app_config>

2) For GPU-only apps.

<app_config>
<app>name</app>
<gpu_versions>
<gpu_usage>.xx</gpu_usage>
<cpu_usage>.y</cpu_usage>
</gpu_versions>
</app>
</app_config>

Ooops, my bad. I had looked back at an earlier version of the documentation, and forgot to come back forward to the present day before copying and posting.

Try these instead - and let's hope I don't get duplicated </app> tags this time.

1) For CPU-only apps.

<app_config>
<app>
<name>name</name>
<max_concurrent>N</max_concurrent>
</app>
</app_config>

<app_config>
<app>
<name>name</name>
<gpu_versions>
<gpu_usage>.xx</gpu_usage>
<cpu_usage>.y</cpu_usage>
</gpu_versions>
</app>
</app_config>

Hi Richard,

It seems you've the lead with this new feature testing ;)

I discovered a new unexpected feature (7.0.41).
A task that may not start because of the max_concurrent setting, is still counted for the work buffer for other projects.
With a low cache that will lead to idle cores.

Running on a quad 100% CPU/all processors and a low cache of 0.01.
No GPU at the moment.
After the last GPU task ended only 3 CPU tasks running and 1 WCG CEP2 waiting (max 1 and already 1 running).
Because of the estimated time for that waiting task is 11 hours and my low cache, it will not ask work for other projects, so 1 idle core as long as that task isn't started.

CP

Already we've made that conclusion off-line in discussion with knreed **. Also, if the user goes wild, too much work could get cached of the max_concurrent and eventually go "too late". As the developer indicated, something would give. How's the work submitting project to know the user has set concurrency restrictions... the buffer is the buffer, and if full it's full. Backup project, or at least another project outside the most wanted, to fill those instances.

In the case of CEP2, where we have the fortune of being able to control how many "in progress", I've set the number to 1.5 times a single thread on a 1 day buffer. So far, it's running 24/7 seamless CEP2 on one thread [now on 7.0.42]. Sometimes 2 are ready to start [because a CEP2 job ran shorter than normal], sometimes 3. The user is in charge to tweak the settings. So far, where I've set other sciences to run 4 max concurrent on an 8 core, not walked into the idle yet, but that's with a 5 way WCG science mix... total 43 tasks waiting in queue. Works wonderful so far.

** Some stuff I've been made to understand will have to wait for 7.2. The focus is now to get a client that does not require the app_info hoopla for multiple GPU tasks and get rid of the anonymous platform causing problems. The second focus is to limit the IO intense, speak CEP2 to not run on more threads than specified, to prevent inefficiency and or user impairment when crunching during use is allowed. Think both issues have been met.

I haven't noticed any problems with CPU apps, but for GPU apps there seems to be perhaps a '<' test where there should be a '<=' test.

<gpu_usage>0.50</gpu_usage>

only allowed one task to run, but

<gpu_usage>0.49</gpu_usage>

allowed two tasks.

Backup project, or at least another project outside the most wanted, to fill those instances.

app_config.xml is first ignored after a reset of the project.
The mentioned apps should at least once be stored in the client_state.

A bit confusing text in message event "World Community Grid 12 dec 14:19:42 app cep2 not found in app_config.xml"

The app cep2 is in the app_config.xml, but not in the client_state.xml

Crystal Pellet, I'd thought the idle core would initiate a call to a backup project, but as you surmised too, there being no buffer room. If that weakness could be overridden for a backup project task [those that only supply minimal work to keep a core occupied], that would be the cream on top of the icing on the cake.:D

edit: Something the developers may want to think about [if only for a blond moment]: Presently a client restart is needed to read in the app_config.xml [mistakenly, thought that the RPC call, rereading the settings, came from disk and not from memory cache]. My thinking is that if doing the "read config file" on the advanced menu, could that menu option be expanded to also read in the app_config files, for instant application?
____________
Coelum Non Animum Mutant, Qui Trans Mare Currunt

NM! I had a major brain cramp.