Currently BOINC wants 15 cores out or 16 (1 core is dedicated for GPU and system). Is there anyway to split those cores in 3 groups of 5?
Does it change anything other than the run time if this is possible?

I posted an app_info.xml file here, just change both "1" to "5".

---

Ok...I looked..but I don't follow nthreads

so I want to take your (and I found others of the same nature when looking up nthreads) and I don't quite follow how you can me it 3 tasks simultaneously and each using 5 cores. I am not sure what parameters to adjust.

I know ncpu would be 5, but max concurrent? is that 3? and then nthreads is what?

15 cores dived by 3 tasks for 5 cores per task......all simultaneously

<app_config>
 <app_version>
  <app_name>milkyway_nbody</app_name>
  <plan_class>mt</plan_class>
  <avg_ncpus>5</avg_ncpus>
  <cmdline>--nthreads 5</cmdline>
 </app_version>
</app_config>

Use this. Max. concurrent is optional and not needed here, it's just for applications, which cause issues if too many of them run at once, with that app_config.xml file BOINC won't run more than 3 with your settings anyway.

---

Great! Thanks for the script!
I put it in play, but there is something odd going on with CPU%
One is at 37, one is at 84 and one is at a miserable 14.
Gets even weirder...close down BOINC and restart, Now one tasks is 136% The others are 84 and 78.

Until you crunch and return few tasks using that file I can't see if it's working, right now you have no tasks in progress.

---

Great! Thanks for the script!
I put it in play, but there is something odd going on with CPU%
One is at 37, one is at 84 and one is at a miserable 14.
Gets even weirder...close down BOINC and restart, Now one tasks is 136% The others are 84 and 78.

Not all tasks are identical in the amount of data they have in them, some have more and some have less that's why we crunch them.

What does <cmdline>--nthreads 5</cmdline> do? Should it match <avg_ncpus>5</avg_ncpus>, so if you want to use 3 cpus per task, --nthreads should also be 3?

The nthreads parameter is ONLY for MT tasks. It sets the maximum number of threads per task to use. For the OP who wanted to run on 15 threads total for the host, that works out as 3 tasks in total using 5 threads each.
You can drop the ncpus value entirely as it is ignored by the nthreads parameter setting.

---

The nthreads parameter is ONLY for MT tasks. It sets the maximum number of threads per task to use. For the OP who wanted to run on 15 threads total for the host, that works out as 3 tasks in total using 5 threads each.
You can drop the ncpus value entirely as it is ignored by the nthreads parameter setting.

I seemed to recall some posts about N-body not actually using the --nthreads parameter but a cursory search didn't find anything so I conducted an experiment on one of my systems with enough cores to make it a proper test.

I normally allow 9 CPU threads for BOINC on the system I tested -- its normal app_config.xml is

<app_config>
  <app_version>
    <app_name>milkyway_nbody</app_name>
    <plan_class>mt</plan_class>
    <avg_ncpus>3</avg_ncpus>
    <cmdline>--nthreads 3</cmdline>
  </app_version>
  <project_max_concurrent>2</project_max_concurrent>

I reduced my queue size to make sure I didn't get swamped with new work, removed the avg_ncpus line and re-read the config files. It immediately suspended one of the two N-body tasks it had been running, as if the client's scheduler now thought tasks used all 9 threads :-) -- the task that carried on running continued to use three threads... I looked at client_state.xml and the app_version section for nbody now included an avg_ncpus value of 9 (which explained the scheduler behaviour!)

It then fetched one new work unit, which apparently wanted 9 threads so I suspended that one before it started, restored the normal app_config.xml and got two tasks running again...

On another (smaller) machine I tried an app_config.xml file with avg_ncpus less than the total allowed to BOINC and without the command-line parameter value option. That happily ran tasks utilizing the required number of threads, despite the absence of --nthreads!

So that left the question of how the executable decides on the thread count... Every task that starts up gets a file called init_data.xml in its slots directory entry; that file contains a lot of information from various places, including an ncpus value which appears to be the same as the avg_ncpus value in the app_version data at the time the task is started (or restarted on a BOINC restart?) It seems likely that the N-body app digs the thread-count out of that file.

I have no doubt that other OpenMP programs may well respect a thread-count parameter of some form, but it certainly appears that N-body doesn't :-)

Cheers - Al.

The executable decides based on the <cmdline> as that's what is passed to it by the BOINC client, <avg_ncpus> is for the BOINC client itself. So in general they should be the same, if ncpus is missing, the client will use the default value from the project as you have seen. They can be also different, but that's just for very special cases.

---

Link - I saw your reply and it made me wonder if the client I was testing on had got confused at some point...

So I restarted the one I used for my experiments and repeated some of the simple tests and it now seems to respect --nthreads if it is present, but it is still using the count of available CPUs (based on avg_ncpus if that is present) when -nthreads is unavailable. That seems to be how I would've expected it to behave, despite my earlier experimental observations to the contrary :-)

I am at a loss to explain the apparent change in behaviour away from the [unexpected] behaviour I observed :-) -- I think the moral might be to always include avg_ncpus and have it equal to the --nthreads value "just in case"... As mentioned elsewhere, it will also have the useful side-effect of keeping the client scheduler properly informed as to CPUs in use!

Thanks for making me have another look; I wasn't that happy with what I thought I'd found :-)

Cheers - Al.

P.S. I had already noticed that BOINC Manager seems to report the CPUs count that was current when tasks were downloaded (until after a restart...) but I'd been monitoring thread usage by looking at stderr.txt in the task's slot directory and with a system tool which always showed one more thread than the number OpenMP reported in the stderr file. There always seems to be an apparently idle thread, even on my system where there's never been an app_config file - I presume it's the checkpoint handler and/or some sort of "watchdog"

[Edited to add reminder about avg_ncpus and the client scheduler]