LHC@home

Hi All,

we have a weird problem since deploying new mini-PCs with AMD Ryzen 5 PRO 5650G (6+6core). The limits are set in our compute preferences and show up in the event log after "Update" e.g.

...
Wed 01 Oct 2025 12:00:22 PM CEST | LHC@home | update requested by user
Wed 01 Oct 2025 12:00:25 PM CEST | LHC@home | Sending scheduler request: Requested by user.
Wed 01 Oct 2025 12:00:25 PM CEST | LHC@home | Not requesting tasks: don't need ()
Wed 01 Oct 2025 12:00:29 PM CEST | LHC@home | Scheduler request completed
Wed 01 Oct 2025 12:00:29 PM CEST | LHC@home | Project requested delay of 6 seconds
Wed 01 Oct 2025 12:01:12 PM CEST | LHC@home | Computing prefs: from LHC@home (last modified 01-Oct-2025 11:59:22)
Wed 01 Oct 2025 12:01:12 PM CEST | LHC@home | Computer location: work
Wed 01 Oct 2025 12:01:12 PM CEST | LHC@home | Computing prefs: no separate prefs for work; using default location
Wed 01 Oct 2025 12:01:12 PM CEST | | Number of usable CPUs has changed from 6 to 3.
Wed 01 Oct 2025 12:01:12 PM CEST | | Computing preferences:
Wed 01 Oct 2025 12:01:12 PM CEST | | - When computer is in use
Wed 01 Oct 2025 12:01:12 PM CEST | | - 'In use' means mouse/keyboard input in last 15.00 minutes
Wed 01 Oct 2025 12:01:12 PM CEST | | - don't compute
Wed 01 Oct 2025 12:01:12 PM CEST | | - don't use GPU
Wed 01 Oct 2025 12:01:12 PM CEST | | - max CPUs used: 3
Wed 01 Oct 2025 12:01:12 PM CEST | | - Use at most 25% of the CPU time
Wed 01 Oct 2025 12:01:12 PM CEST | | - suspend if non-BOINC CPU load exceeds 10%
Wed 01 Oct 2025 12:01:12 PM CEST | | - max memory usage: 15.33 GB
Wed 01 Oct 2025 12:01:12 PM CEST | | - When computer is not in use
Wed 01 Oct 2025 12:01:12 PM CEST | | - max CPUs used: 3
Wed 01 Oct 2025 12:01:12 PM CEST | | - Use at most 50% of the CPU time
Wed 01 Oct 2025 12:01:12 PM CEST | | - suspend if non-BOINC CPU load exceeds 15%
Wed 01 Oct 2025 12:01:12 PM CEST | | - max memory usage: 22.99 GB
Wed 01 Oct 2025 12:01:12 PM CEST | | - Suspend if running on batteries
Wed 01 Oct 2025 12:01:12 PM CEST | | - Store at least 0.10 days of work
Wed 01 Oct 2025 12:01:12 PM CEST | | - Store up to an additional 0.50 days of work
Wed 01 Oct 2025 12:01:12 PM CEST | | - max disk usage: 25.00 GB
Wed 01 Oct 2025 12:01:12 PM CEST | | - (to change preferences, visit a project web site or select 'Options / Computing preferences...' in the Manager)
Wed 01 Oct 2025 12:01:12 PM CEST | | Suspending computation - computer is in use
Wed 01 Oct 2025 12:01:12 PM CEST | | Suspending file transfers - computer is in use
...

The ATLAS jobs start with Status "Running (12 CPUs)" and consume 1200% (or top load average 12). On older hardware there is no problem, CPU limits are honored by boinc and the ATLAS jobs just fine (currently TVnLDm262N8n9Rq4apOajLDm4fhM0noT9bVof3QYDmIK7LDmwi3San).

Our OS is
skluth@belleA115a:~$ lsb_release -a
...
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20250920

and identical on PCs (trust us on that one, we deploy the OS centrally). I am not sure how to debug this, since things look ok on the boinc side. I would need some help how to look at the job log files to figure out why the ATLAS jobs don't take over the compute limits present in boinc.

Cheers, Stefan

I meant TVnLDm262N8n9Rq4apOajLDm4fhM0noT9bVof3QYDmIK7LDmwi3San is the problem job ID not honoring the compute limits.

Update:

now all ATLAS tasks (native_mt) don't honor the boinc CPU limits (25% CPUs, 25% CPU time) and load all available cores to 100%.

This is not easy to debug since I am not root on the clients (desktop PCs running Suse tumbleweed, /cvmfs and apptainer) and many of the files written by boinc are only *owner* readable. I am group "boinc" but that does not help reading these and so I am flying blind.

Is there a way to configure boinc to write everything group readable?

I have not tried to go back to vbox_wrapper instead of native but I would like to avoid going back.

You may try to set some options via cc_config.xml and app_config.xml.

in the <options> section of cc_config.xml:
- set <ncpus>N</ncpus> with N being the max number of cores you want to donate to BOINC on that computer
- set all other BOINC CPU limits to 100 %

in app_config.xml:
- create an ATLAS section that looks like this

<app_config>
  <app>
    <name>ATLAS</name>
    <max_concurrent>M</max_concurrent>
  </app>
  <app_version>
    <app_name>ATLAS</app_name>
    <plan_class>native_mt</plan_class>
    <avg_ncpus>4.0</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>
</app_config>

ATLAS is known to be most efficient if it is configured as 4-core task.
Hence, set N=4*M.

Tell BOINC to read config files or restart BOINC.

Solution:

do a

$> boinccmd --project <project URL> reset

on each client, this resolved the issue. No idea what went wrong though ...

Cheers, Stefan

https://www.man7.org/linux/man-pages/man1/taskset.1.html

Limit cores/threads with taskset

now all ATLAS tasks (native_mt) don't honor the boinc CPU limits (25% CPUs, 25% CPU time) and load all available cores to 100%.

I see this bug in Boinc 8.2.4 but not in Boinc 8.0.4 (Linux)

I have seen similar behaviour with a different MultiCore-Project (MIlkyway) and BOINC-Client 8.2.5

If there is a local app_config.xml, the client uses the configured settings from this. If there is no app_config.xml, the client ignores what on the project-preferences is configured and uses the last config it remembers, regardless of the setting on the project-preferences

Seems to be a bug in client since 8.2.4 and higher

---

Supporting BOINC, a great concept !