Cosmology@Home is at it again, sending me 32-CPU jobs. They *work*, kinda, except that they don't actually consume any CPU time, but they do block 32 out of 36 hyperthreads (i9 10980XE, 18 HT cores), which means the machine is under-used.

Is there a way to tell the project to send me jobs for at most 8 CPUs? If so, does it mean I have to exclude it *again*(1) on Science United and add it manually? I don't mind helping the project, but my PC isn't there for their exclusive use, especially if they are going to reserve it but not actually use it.

(1) Some time back, I excluded it based on this misbehaviour, and I thought I'd give it a chance. Looks like I was wrong. Or maybe they don't get information from Science United about who has excluded their project.

"Science United" is about giving the projects control of your computer.
If YOU want to control how projects use your computer, then stop using Science United, and use the original BOINC instead.

OK, thanks. That's more or less what I thought. That said, is there a way to restrict projects so I can limit the maximum value of N in an "N CPUs" work unit / task?

Or is this something that each project does differently, if at all?

Thanks again for confirming my suspicions.

If you are running "pure" BOINC (that is, not using Science United) then there are two avenues available, one via the web and the other local to your PC. Personally I have found the local solution to be a better match to my needs than the web-based one.

If the application is a MT (multi-thread) one as likely by what you describe, BOINC has a native configuration setting in the app_config file to limit the number of threads a MT application is allowed to use.
https://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration

Specifically this part referencing nthreads. Just reduce the number from 32 to 4 or whatever how many you want the app to use.

[<app_config>
[<app>
<name>Application_Name</name>
<max_concurrent>1</max_concurrent>
[<report_results_immediately/>]
[<fraction_done_exact/>]
<gpu_versions>
<gpu_usage>.5</gpu_usage>
<cpu_usage>.4</cpu_usage>
</gpu_versions>
</app>]
...
[<app_version>
<app_name>Application_Name</app_name>
[<plan_class>mt</plan_class>]
[<avg_ncpus>x</avg_ncpus>]
[<ngpus>x</ngpus>]
[<cmdline>--nthreads 7</cmdline>]
</app_version>]
...
[<project_max_concurrent>N</project_max_concurrent>]
[<report_results_immediately/>]
</app_config>

If the application is a MT (multi-thread) one as likely by what you describe, BOINC has a native configuration setting in the app_config file to limit the number of threads a MT application is allowed to use.
https://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration

Specifically this part referencing nthreads. Just reduce the number from 32 to 4 or whatever how many you want the app to use.

[<app_config>
[<app_version>
<app_name>Application_Name</app_name>
[<plan_class>mt</plan_class>]
[<avg_ncpus>x</avg_ncpus>]
[<ngpus>x</ngpus>]
[<cmdline>--nthreads 7</cmdline>]
</app_version>]
...
[<project_max_concurrent>N</project_max_concurrent>]
[<report_results_immediately/>]
</app_config>

OK, that looks interesting. However, it doesn't seem to work for the existing jobs. If I look at their properties:

Application                camb_boinc2docker 2.05 (vbox64_mt)
Name                       camb_boinc2docker_1265887_1640858474.018410
State                      Ready to start
Received                   30/12/2021 11:18:28
Report deadline 06/01/2022 11:18:28
Resources                  32 CPUs
Estimated computation size 18,000 GFLOPs
Executable                 vboxwrapper_26200_windows_x86_64.exe

So, a few questions:

1. Which of "camb_boinc2docker 2.05 (vbox64_mt)" and "camb_boinc2docker_1265887_1640858474.018410" goes in the <app_name> tag? (the numbers after "camb_boinc2docker" in the second type are different on each job).

2. Or do I have to trash the existing jobs and start again?

3. Or should I just give up and leave Cosmology permanently excluded? (I'm leaning toward this, since these jobs never actually compute anything - they are *all* aborted for taking too long after a bit less than nine minutes.)

4. Or dump Science United?

EDIT: I don't really want to dump Science United, because I like to see the unusual things it proposes, but I want it to propose projects whose calculations actually *use* my computer...

Option 4 is the best.
Doing so will give you access to all the options already built into BOINC as well as YOU being able to choose which projects you support.

OK, that looks interesting. However, it doesn't seem to work for the existing jobs. If I look at their properties:

One of the quirks of app_config.xml is that it doesn't update the displayed information about already downloaded tasks, but does (if you've got the syntax right, and issued a 'read config files' instruction) act on most of them immediately.

The new settings will be displayed for new tasks downloaded after the new file is activated.

Not familiar with Cosmology apps but to hazard a guess at to what the app_name is . . . I would bet it is simply camb_boinc2docker.
A check in the client_state.xml for the the Cosmology project section would confirm that.