LHC@home

A max number of 8 is a bit old fashioned with today standards and most times the computer needs to do other things as well so Unlimited is to much. The step is too big from 8 to Unlimited.

Would it be possible for you to change so we have the choice of 16, 32 and 64 as well?

I want to run all the LHC jobs at 100% but leave 4-8 threads for other duties.

[edit]
for me it would be optimal to set Max # CPUs to 80 and set Max # jobs to Unlimited but I'm just one of thousands of users so I think 16/32/64 would be a good compromise :)

I think this is a BOINC feature as its the same on all servers, so it would need to go there for feature request.

I just use unlimited and set the settings client side to my preferences.

I think that setting is unique to LHC because of the nature of the LHC software.

I'm running 7 other projects in medicine/biology and astrophysics and non of them has these setting so I think it's a LHC added thing.

You have the global_prefs.xml and global_prefs_override.xml config files in Boinc there you can control the number of CPUs used and how much it's allowed to use of each core/thread.

<max_ncpus_pct>100</max_ncpus_pct>
<cpu_usage_limit>100</cpu_usage_limit>

These parameters works very well with all other projects but LHC seems to ignore them. Maybe it's because LHC run in Oracle virtualbox.

They only work when you have unlimited since the 8 overides this settings:

12-Mar-25 21:11:30 | | Processor: 64 AuthenticAMD AMD Ryzen Threadripper 7970X 32-Cores [Family 25 Model 24 Stepping 1]
12-Mar-25 21:11:30 | | Computing preferences:
12-Mar-25 21:11:30 | | - When computer is in use
12-Mar-25 21:11:30 | | - max CPUs used: 41

You can use these to limit the projects app

<app_config>
<app>
<name>rosetta</name>
<max_concurrent>12</max_concurrent>
</app>
<app>
<name>rosetta_python_projects</name>
<max_concurrent>4</max_concurrent>
</app>
</app_config>

It would be nice if the max_concurrent setting would handle cores (threads) instead of tasks. Especially for LHC with multithread applications.

---

They only work when you have unlimited since the 8 overides this settings

I set the <max_ncpus_pct>91</max_ncpus_pct> in global_prefs_override.xml to use 80 threads in an 88-thread server and set Max # jobs and Max # CPUs to Unlimited in LHC@home preferences.

I run only LHC on these servers so no need to set per project.

It has been running mixed Theory, CMS and ATLAS for a while now (Theory and ATLAS native and CMS in VirtualBox) and so far, it stays at 80 threads so it seems to be working.

But anyway, it would be nice with a little more choices directly in the LHC settings. Only one place to change, not at every server.

It would be nice if the max_concurrent setting would handle cores (threads) instead of tasks. Especially for LHC with multithread applications.

Create an app_config.xml file for LHC, and include a section similar to this for each project you want to control;

<app_version>
<app_name>ATLAS</app_name>
<avg_ncpus>3</avg_ncpus>
<plan_class>vbox64_mt_mcore_atlas</plan_class>
<cmdline>--nthreads 3</cmdline>
</app_version>

<avg_ncpus> tells BOINC that ATLAS tasks have to be run using 3 threads, while the <cmdline> part gets passed to virtualbox commandline.

This section completely over-rides anything the LHC BOINC servers might send out. Note that you cannot do this with CMS tasks. For some reason I am unable to understand, these need exactly 4 threads or they will fail.

See https://boinc.berkeley.edu/wiki/Client_configuration for complete details on both the app_config.xml and cc_config.xml files.

I've done all that. The problem comes when some of the subprojects run out of tasks and the total number of tasks running need to change to get optimal load for the host. And the very large range of Theory task run times doesn't help either.

---

I've done all that. The problem comes when some of the subprojects run out of tasks and the total number of tasks running need to change to get optimal load for the host. And the very large range of Theory task run times doesn't help either.

Now you are asking for something that BOINC cannot do. Furthermore, what I posted has nothing to do with the total number of running tasks; it only controls the number of threads used by multi-thread capable tasks.
If you are running tasks from several different projects, then the best you can do to try to get what you want is to avoid using <max_concurrent> for the most part, and just let BOINC decide which projects to run.

Now you are asking for something that BOINC cannot do. Furthermore, what I posted has nothing to do with the total number of running tasks; it only controls the number of threads used by multi-thread capable tasks.
If you are running tasks from several different projects, then the best you can do to try to get what you want is to avoid using <max_concurrent> for the most part, and just let BOINC decide which projects to run.

I am running only 1 CPU project, LHC. I think that my request to set limit for concurrent threads instead of concurrent tasks would probably work better on project level i.e. project_max_concurrent. I know that Boinc cannot do it at the moment.

---

Now you are asking for something that BOINC cannot do. Furthermore, what I posted has nothing to do with the total number of running tasks; it only controls the number of threads used by multi-thread capable tasks.
If you are running tasks from several different projects, then the best you can do to try to get what you want is to avoid using <max_concurrent> for the most part, and just let BOINC decide which projects to run.

I am running only 1 CPU project, LHC. I think that my request to set limit for concurrent threads instead of concurrent tasks would probably work better on project level i.e. project_max_concurrent. I know that Boinc cannot do it at the moment.

This is probably because you are thinking of LHC as being a single project. It is not. ATLAS, CMS and Theory are LHC's projects.
Anyway, you probably don't want to do what you are suggesting. ATLAS can optionally be run on more than one thread (up to 8), CMS must be run on 4 threads, while Theory can only use one. I think you would find it very difficult to control the maximum number of threads used by all LHC projects, given those conditions.