In Windows 10, BOINC 7.16.5 (and 7.14.2), Rosetta project. Setting "Suspend when non-BOINC CPU usage is above" does not have any effect when the non-BOINC processes are in Low priority mode.
As computers run a lot of processes and some of them in low priority mode, the setting in its currrent state prohibites the use of BOINC in my case. Does anyone else have this bug? Or is there a workaround somewhere in BOINC settings without having to set up third party process managment programs?

Test case: let BOINC run its project with this Suspend setting at 25%. Start up some CPU intensive program, for example Prime95 and run a Torture test with at least half the cores. In about 20 seconds BOINC suspends the workload as expected. Now change Prime95 process priority to "Low" in Task Manager and then BOINC resumes the work as it should not do.

Guessing here but does setting BOINC client priority to low resolve this? I don't know if that then automatically sets priority of the tasks to low as well. (I defenestrated in 99 so my knowledge of Windows is only from trouble shooting other half's computer and from forums like these.

Fiddling with client priority does not seem to change this behaviour but I think I found the bug from github source https://github.com/BOINC/boinc/blob/master/lib/procinfo.cpp:

// get resource usage of non-BOINC apps
//
void procinfo_non_boinc(PROCINFO& procinfo, PROC_MAP& pm) {
procinfo.clear();
PROC_MAP::iterator i;
for (i=pm.begin(); i!=pm.end(); ++i) {
PROCINFO& p = i->second;
#ifdef _WIN32
if (p.id == 0) continue; // idle process
#endif
if (p.is_boinc_app) continue;
if (p.is_low_priority) continue;

This last if statement looks to me that it ignores all low priority processes in counting the total CPU usage, don't know if there are some bigger issues behind this code or am I not understangind this but at first glance this seems like a bug (or purposely evil choice :D).


Edit:
The "is_low_priority" has its value set in https://github.com/BOINC/boinc/blob/master/lib/procinfo_win.cpp
p.is_low_priority = (pProcesses->BasePriority <= 4);

This is probably a deliberate choice. BOINC sets its own processes, like the Rosetta application, to run at low priority:it should not take any cpu time away from other processes on the computer at any other priority like 'below normal'.

The oddity would seem to be that you have significant processes active on the machine, which you would want to continue running, but which are also set to low priority. Modern operating systems are used to running 100 processes or more: processes are swapped into and out of the available cores many hundreds of times a second, so that each of them can make progress.

If you have significant processes which you want to proceed at 'faster than shared' speeds, but which do not run at an appropriate priority, then perhaps BOINC is not for you. But for most people, the various processes, at their various and appropriate priorities, coexist quite happily.

Kind of get the logic but cannot agree. The problem is the setting "Suspend when non-BOINC CPU usage is above" is then untrue, it should be something like "Suspend when non-BOINC CPU usage is above but not including low priority processes".
Today's PC-s run a lot of low priority processes, even popular programs like Chorme, Firefox, Slack.. have tens of low priority processes, not even talking about backround rendering apps etc where the real problem kicks in. In my case I would just like to run BOINC when CPU total load is less than x%, handling the priorities with third party programs is an option but very tedious.

If there is underlying need for most people to override other low priority processes then this could be fixed with additional settings checkbox: "Include(or Exclude) low priority non-BOINC processes".

My problem with your logic is that you get a process that's by default (as intended by its developers) to run at normal priority and set it to low priority, and then you blame BOINC for being buggy for not suspending it, because you set it to low priority but that still uses up quite a lot or all of the CPU core(s) just as its developers intended.

I'd say, try finding an actual low priority process that uses up a lot of processing power and see how BOINC reacts to that. And if it then still behaves like that, then call it a bug. But deliberately changing the running priority of programs to call out a bug in BOINC is like telling a car manufacturer that his car drives rotten because you let out the air from all the tires.

---

What I call buggy, or should call misleading? is that the setting checkbox states one thing but actual behaviour is different. Regular users should not need to know about prirorities at all and frequently user has no control over this in third party programs, just want to keep CPU usage in x range. Thing is it is not clear that "non-BOINC usage" is selective to higher than low priority processes.
I have no problem if BOINC runs even normal or high priority (even tho the work processses run low) but currently cannot control the suspension very well.

One real world example would be 7-zip. BOINC settings are: use at most 50% CPU, suspend 25%. When compressing large amount of data at backround then BOINC does not suspend, CPU usage gets near 100% and CPU starts getting hot and noisy.

Regular users should not need to know about priorities at all ...

And they don't. But I don't think that examples like 'using 7-zip to compress large amount of data' or 'backround rendering apps' count as regular uses - I'd call them specialist or advanced uses. And, like you, specialist or advanced users can work these things out for themselves, without adding a tl;dr text string that will have to be translated into 50-odd languages. And will confuse the regular users who, as you say, won't understand the terms referenced.

If consensus is that the behaviour is intended then i'm ok with that, just would be nice to have possibility to change it in BOINC (or direcly in cc_config.xml without UI). Most my computers are dedicated enough or virtual that have their own VM prioritization settings that those process suspend edge cases do not appear. Problem is mostly in main computer that has wide array of workloads where wanted to try if background CPU cycles could be used productively and completely transparently without affecting all other workloads. That also means minimizing DPC latency spikes, cache invalidations, thermals and noise in check.

You already found the source code, so download it, adjust the code to your liking, build it and use that for yourself.
https://boinc.berkeley.edu/trac/wiki/CompileClient

---