Now I see on one host that it is getting only 1 Theory task at a time. And there is only 1 task waiting for crunching. So number of tasks in progress is max_concurrent (from app_config) + 1.

Do you have set the number 1 in the prefs for Max # CPUs?

No, I have both hosts set to 4 max CPUs.

My assessment of the situation turns out to be wrong. The win10 host (Boinc 7.16.5) is still doing what I said above but the win11 host (Boinc 8.0.2) didn't get new Theory tasks and was getting free CPU cores. So I enabled the CMS work for that host and I just got 8 of those.

---

There does seem to be something different with the number of WUs.

I have unlimited set for both Max # CPU & Max # jobs, with run all applications.

My higher end computers, have about 40-50 WUs and are requesting work but are not given more so they are not fully utilised.

The cap for CMS seems to be 8 and for 10 Theory, not sure for ATLAS as I don't have so many of these at the moment. so it seems like unlimited is no longer unlimited.

I don't max_concurrent set, just that Theory and ATLAS should only use 1 core per job/task.

I am making the same experience: for one of my PCs (16 cores) I have set the max. number of Theory tasks to "unlimitied", but I get only 10. How come?

I am making the same experience: for one of my PCs (16 cores) I have set the max. number of Theory tasks to "unlimitied", but I get only 10. How come?

Might indeed be a hard cap on the server side. I noticed one such cap at TN-Grid where each host can get at most 6 tasks/thread (not core), regardless of any other settings.

---

I'm also seeing a cap of 8 CMS tasks per PC irrespective of the cpu core count or the max work cache set. The only way to feed your PC with 100% utilization is to run multiple boinc clients if you have high core count setup with sufficient RAM and wanting to run CMS tasks only.

WIth multiple boinc clients, on linux machines I've not seeing this VBoxManage.exe error about registering/attaching the CMS_2025_04_08_prod.vdi virtual hard disk (maybe the first task but ok subsequently) but not on Windows machine.

I prefer to run CMS as the run times don't fluctuate as much as Theory tasks with CMS task seems to have a cap on the run time of 64,800 seconds. I had a few Theory tasks that run for days.

I'm seeing the same caps for Theory and CMS here as well. But Atlas seems different. Last new tasks from Atlas were on 14th of November and I received 37 for a 8/16 core CPU and 22 for 16/32 core CPU. The limit on server side used to be 16 for both of those CPUs. There wasn't enough tasks available to actually see what is the limit now but definitely the limits have changed for Atlas too.

---

WIth multiple boinc clients, on linux machines I've not seeing this VBoxManage.exe error about registering/attaching the CMS_2025_04_08_prod.vdi virtual hard disk (maybe the first task but ok subsequently) but not on Windows machine.

This was not related to the number of BOINC instances running on the same host.
Instead, it was related to a possible race condition related to vboxwrapper.

Vboxwrapper 26210 used here for ATLAS/CMS/Theory mitigates/recovers from those errors on Apple/Linux/Windows.

ATLAS got a bit more work so I have an update:

Name                           Value
----                           -----
Theory                         19
CMS                            6
ATLAS                          0

Theory                         7
CMS                            3
ATLAS                          1

Theory                         10
CMS                            8
ATLAS                          40

Theory                         16
CMS                            8
ATLAS                          9

Theory                         10
CMS                            8
ATLAS                          2

Theory                         10
CMS                            8
ATLAS                          40

Seems like maybe ATLAS cap is, 40.

To my liking 40 is too high especially with these 1000 event tasks.

---

In theory, BOINC, will send out tasked based upon preferences, e.g. if if you store 0.1 day of work and the tasks take 10 days, then you would not be storing many so a cap of 40 would not be reached easily.

e.g.

LHC@home	11/19/2025 9:17:41 PM	Not requesting tasks: don't need (CPU: job cache full; Intel GPU: no applications)

Things seem to have gone back to normal.

For Therory, 4/6 have more than 10, the ones with less than 10 are probally as Harri and I were discussing, they are limited by there compute speed and small cache size.

For CMS, 1/6 has more than 8, so could be.

For ATLAS, none have more than 40 so this could still be the cap.

caps are back to 10,40,8

caps are back to 10,40,8

I don't understand at all the cap of 10 for Theory - why? One of my rigs has 2 CPUs 8 cores each, so I could crunch 16 Theory tasks concurrently. Okay, I switched to 4 CMS concurrently.

If it was multicore then it would make a little more sense but still.

The top 5 computers on BOINCStats by RAC have at least 16 cores/32 threads so its not even enough to max out these if a user just wanted to run Theroy.

The top computers are running 256 threads so 10 is a few % of the total capacity of these machines

Getting a lot of Atlas download errors at the moment. First the server aborted all my downloaded Atlas tasks and now new downloads are failing.

---

Yes, seems so.

Are any of guys getting gateway timeouts around this time everyday? They clear up after a bit but I think it's been happening every day for me for about the past week?

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=lhc@home&from=now-7d&to=now&refresh=30m
See the Status and Response time graphs on that page. There are clearly times when it takes a long time the project to respond but I don't know if times correlate your observations.

---

So I think they line up with when I'm seeing the timeouts but it's happening over night so I just wake up to a backed up upload queue. However it looks like there's a new problem.
I'm seeing server cant open data base in the event logs.

In reply to Harri Liljeroos's message of 10 Mar 2026:

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=lhc@home&from=now-7d&to=now&refresh=30m
See the Status and Response time graphs on that page. There are clearly times when it takes a long time the project to respond but I don't know if times correlate your observations.

exactly - response times have again been bad lately :-(