The advantage of using app_config is that you don't need to suspend any units (and so stop new units arriving) in order to restrict work on particular projects. It helps to prevent overloading with high dependency projects such as arp1 & mip1.

It is a simple piece of coding:

<app_config>
<app>
<name>arp1</name>
<max_concurrent>4</max_concurrent>
</app>
<app>
<name>mcm1</name>
<max_concurrent>4</max_concurrent>
</app>
<app>
<name>mip1</name>
<max_concurrent>4</max_concurrent>
</app>
</app_config>

There are 4 lines for each project that you wish to restrict and any not coded would not be restricted. There is also a line at the beginning and another at the end.

My example shows arp1, mcm1 & mip1, but you could equally use scc1, hsst1 or fahb.

The second line of the 4 gives the project to be restricted and the third line gives the maximum units to be crunched at any one time. Please note that inserting a 0 (zero) does not work.

The coding above is for a machine with 8 threads and allows for a maximum of 4 arp1 units with allowance for up to 4 each for the other 2 projects in case of an absence of arp1 units. Generally arp1 units start fairly soon after arrival because they are longer and the others clear more quickly.

The module should be in an otherwise empty file called app_config.xml in a folder that you will have, probably called C:\programdata\BOINC\projects\www.worldcommunitygrid.org

To activate it you click on the Options tab and select Read config files.

I use it in conjunction with a Device Profile setting of 6 arp1 units and 5 each for mcm1 & mip1, together with cache settings of 1.5 + 1.5 days.

I hope it helps.

Mike

My settings do an update every time a unit finishes and as the mcm1 & mip1 units are short, an update takes place frequently.

Mike

Mcm1 & mip1 are readily available so their quotas are topped up immediately they finish which is about every half hour. At the same time, arp1 units are requested if that quota is not full.

The problem with randomisation is that any form of update can miss them.

If I had more threads available, like you seem to have judging from your badges, the updates would be even more frequent.

The other thing that I find is that if I had a higher cache of arp1 units, I would need to run more to keep my machine listed as 'reliable' and that would mean that the units would take longer. As I think that all the projects deserve our support, I prefer the higher efficiency of running a mix of projects on my machine.

You said that my way stops requesting work, but my way keeps requesting more every half hour or so.

Mike

For the holiday period I have had at least 12 WU in the que with two of my machines with a total of 12 threads. I have set each with a 2 day cache and kept them topped up with MIP work. My fast machine crunches ARP in 15 hrs and the other one takes 52 hrs. Hope to get ruby by the end of next week.