I should add that app_config.xml needs to be installed on each machine individually if you want to use it on that machine.

The profile settings can differ from machine to machine, but you only have 4 different profiles available.

Mike

Correct, if you only want one extra ARP work unit in the queue. Note that if you are opted in to other projects (and you will be if you are only using half your threads for ARP) and you don't specify limits either for concurrent or maximum downloaded units for those other projects, the client could then legitimately just download and process only units for those and ignore ARP. It of course depends on the WCG servers and the work being handed out at the moment the client requests more so something to keep in mind. These are maximums being specified and not minimums.

If you do cap MCM for instance the client will be forced to download some ARP to try to get to your specified "cache" value in the online preferences. This brings up a quirk where if there are any projects you have not opted into, if your caps for the ones you are doing are seen by the client as not being enough to get to that cache value, it will go and download from those projects you don't normally work on to get more of a backlog unless you uncheck "If there is no work available for the project(s) I have selected above, please send me work from another project."

The client can also hold onto several tasks that it has uploaded but not yet reported. These do unfortunately seem to count against the limits you set online for downloaded tasks (but not for max concurrent). So if you really ride the knife's edge with just one extra work unit, it may be worthwhile to specify the "report_results_immediately" option to keep from losing all backlog as soon as just one completes. I only do that for ARP since they take so long to process. I let the client naturally batch together task reporting for shorter ones like MCM so the servers aren't constantly getting hit with those (but this can require a larger download buffer to avoid unused threads waiting for new work).

   <app>
      <name>arp1</name>
      <max_concurrent>4</max_concurrent>
      <report_results_immediately/>
   </app>

Sorry if I'm getting too into the weeds here. It all depends on just how much control and micromanagement you want to do.

There's actually a bit of a clever "hack" to get around this. I've written up a Google Doc describing it for you.

On this system I have 6 threads (recently upped from 3) dedicated to ARP with a cache of only just one more. Their turnaround time varies from 10 to 17 hours, with a clear mean of 12 hours. In this way I can finish 12 ARP1-tasks per day by returning one ARP1-result each 2 hours.

Each CPU is different, but Mike's advice to use only half the cores is the best starting point. On my Ryzen 3600 (Ubuntu 20.04.2) I restrict it to four cores with an app_config.xml (or a second BOINC instance in some cases). That chip has a lot of nice cache that the ARP's like.

It then depends on what is running on the other cores, and how much cache they take. At the moment, the other eight cores are running SiDock (CurieMarieDock), and the ARP's are taking a little over 11 hours. I think Win10 will be a little longer for the ARP's. The CM Dock take a bigger hit on Windows. You could use MCM with ARP and do well on either OS.