Hi all,

many thanks for the help!

@Mike.Gibson: I didn't create another profile because it looked a little bit redundant. Also, didn't want to make specific project related settings.

@BobbyB: it worked! After I configured <max_ncpus_pct>67.000000</max_ncpus_pct> and did boinccmd --read_global_prefs_override, I got 4 boinc tasks active on that 6 core machine. Thank you!

@entity: <NCPUS>4</NCPUS> in cc_config.xml and boinccmd --read_cc_config didn't help, I still seen 6 tasks. Also it is not recommended in the documentation:
https://boinc.berkeley.edu/wiki/Client_configuration
<ncpus>N</ncpus>
Act as if there were N CPUs; e.g. to simulate 2 CPUs on a machine that has only 1. Zero means use the actual number of CPUs. Don't use this to limit CPU usage; use computing preferences instead.

Thanks guys once again for the help!

Quite frankly, the ncpus option in the cc_config.xml file is a documented option. If they would have provided a ncpus option in the override file, I would agree that it would be better to use the override file. However, they only provided a percentage based approach to the limit the cpu usage which doesn't always result in a whole number. That leaves the user with a trial and error approach to getting what they want. It's nice to say, "Don't use this to limit CPU usage" but explain why not. Regardless of what XML option one uses in any BOINC file, it could change in the future. Even the override file.

But like most programming things, there are multiple ways to accomplish a task and as long as the user gets what they need, they should use what is comfortable for them. Glad to see it worked it for sepmsk

It really is trial and error. Due you specify 66% or 67% or does it matter. Will any percentage in the range of 67% to 83% give you 4 or will you get 5 once you are more than half way to 83%. Kind of a rhetorical question because I have run into the trial and error problem when using the GUI interface (which populates the override file).

The reason I used to use the ncpus parameter and set the value greater than the number of actual threads was to get enough work to keep the queues full or when "bunkering" for challenges but being limited by the project to a certain number of WUs per core. WCG used to be 35 back in a day. I think it has since been increased to around 70. Of course that required an app_config file to keep from running more processes than available threads.

BOINC can see more than 64 cores. I have tested it up to 256 and it works fine with no customization. There may be an OS limitation where the OS doesn't present the total number of threads available to BOINC. I believe the desktop version of Windows was/is limited to a certain number of cores (perhaps 64). If the user wanted to use more they would have to purchase the server version of the code. I wouldn't know if that is still the case since I haven't used Windows since Windows 7.

OK I found it. It was ARM:
https://www.worldcommunitygrid.org/forumswcg/...ead,42576_offset,0#631326
Wanted to be sure it was not my imagination just to support my argument.

As an experiment I went back and tried it (with the GUI) 66% does not do it but 67% does. I am guessing 66.666667 would also do it but am not that curious.. So that logic suggests anything up to 83% would give you 4 of 6 and 84% would give you 5 of 6.

There. It's documented.