When I'm not actively using my computer I let BOINC use 75% (6 of 8 cores). When I want to actively use it, I go into the BOINC menu and lower the CPU usage limit to 50%.

All previous versions would suspend tasks to being CPU usage to below the new limit. 7.14.2 does not do this, it does not suspend anything. It does, sort of, honor the new limit in that if I manually suspend a task, BOINC will not start a replacement.

I think the old way of automatically suspending tasks is correct.

++PLS

---

Hi! What project is your computer running? What application? What kind of settings have you stored for work cache?

In his other thread on CPU time, Paul is asking about wrapper apps. Wrapper apps typically don't checkpoint, and BOINC won't suspend a task that hasn't checkpointed - that's been the case for years, and is not new for v7.14.2

Paul, please consider that a possible change in work mix might be causing this when you reply to Richie's questions: I'll reply to the CPU time issue later, but I have a busy day first.

Nice to know. The project in questions is LHC. I've been running LHC for a long time and every previous version would automatically suspend tasks when the allowed CPU was lowered.

If a task doesn't checkpoint, what happens if you hit the Suspend button on it. Because that suspends the task. And it will later resume with little change in time remaining, so I doubt the task is being restarted.

Now what is new is that I have only just started getting multi-cpu tasks. But I'm pretty sure that for the short period I was running the previous BOINC that auto-suspend was working.

I'm fine with dropping back a BOINC version and testing to be sure. So, questions:
1. Where can I find an install package for the previous BOINC release?
2. Are there any problems with installing the older package over a newer?

++PLS

---

I'm fine with dropping back a BOINC version and testing to be sure. So, questions:
1. Where can I find an install package for the previous BOINC release?
2. Are there any problems with installing the older package over a newer?

Here is the page where also one previous version can be seen:
https://boinc.berkeley.edu/dev/download_all.php

But other versions are "there" also. Them can be downloaded by changing the version numbers on the link. There is now https://boinc.berkeley.edu/dl/boinc_7.12.1_windows_x86_64.exe available, but if you remember running for example Boinc version 7.12.0 ... just change the link to https://boinc.berkeley.edu/dl/boinc_7.12.0_windows_x86_64.exe and proceed with that.

I don't know if this method would be the best, but I always create a new Boinc Program folder for a new Boinc version. This has worked well for me.

I leave the old folder there (name of the old one could be for example "Boinc_7.12.1"). Name for the new folder could be "Boinc_7.14.1".
Then I would start the Boinc installer and choose 'Advanced...' (or was it 'Custom') and I would choose that new folder to be the Boinc Program folder.

After installing process has finished I would run the boincmgr.exe from that new folder. Then if everything seems to be running well I could safely delete the old Boinc Program folder ("Boinc_7.12.1" in this example).

You can take your pick of whatever version you want from

https://boinc.berkeley.edu/dl/?C=M;O=D

(that link displays newest first)

The numbers are {version}, {major revision}, {minor revision}

Major revision: odd numbers are development/test versions (expect bugs): even numbers are getting close to release.

Minor revision: bugfixing towards final release. The smaller the revision number, the more bugs.

Speaking for Windows only: every installer removes the existing program files from the current version, and deploys the new files. When reverting to an earlier version, the installer often reports that the installation failed to complete cleanly. If that happens, simply re-run the installer for the version you're trying to test: it will repair whatever problem it's complaining about and finish the job.

In general, any version will work with your existing projects, applications, and tasks. But there are some boundaries where structures were changed, and you should avoid crossing these. The most recent showstopper like that occurred early in the v6.13 testing phase, in preparation for the release of version 7. Don't revert to v6.12 or earlier without anticipating major problems.

7.14.2 is also not honoring my "Switch between tasks every 10 minutes"

Which tasks, from which projects?

What does <checkpoint_debug> say?

Reverting to 7.12.0 (MacOS 10.13.6) fixes "Suspend when non-BOINC..." but not "Switch between tasks..."

Adding <checkpoint_debug> to 7.12.0 shows (30s checkpoint, 1m switch):

Wed Nov 7 16:02:34 2018 | | Re-reading cc_config.xml
Wed Nov 7 16:02:34 2018 | | log flags: file_xfer, sched_ops, task, checkpoint_debug
Wed Nov 7 16:03:08 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_19_1 checkpointed
Wed Nov 7 16:03:32 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_20_1 checkpointed
Wed Nov 7 16:03:39 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_19_1 checkpointed
Wed Nov 7 16:04:09 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_19_1 checkpointed
Wed Nov 7 16:04:34 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_20_1 checkpointed
Wed Nov 7 16:04:39 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_19_1 checkpointed
Wed Nov 7 16:05:12 2018 | Einstein@Home | [checkpoint] result h1_0109.60_O1C02Cl2In0__O1OD1_109.70Hz_19_1 checkpointed

but I don't get task switches (to Rosetta, Milkyway, SETI) which are "Waiting to run"

Is there more debugging to turn on to see why tasks aren't switched?

Ok, I went back to 7.12.1, with these results:

7.14.2
Allowing 6 CPUs
Running 1 LHC Atlas 3 CPU, 1 LHC Theory 3 CPU.
Drop allowed CPUs to 4
3 minutes later, same two tasks running.

7.12.1 Installed
verify running 7.12.1
Allowing 6 CPUs
Running 2 LHC Theory 3 CPU each.
Drop allowed CPUs to 4
3 minutes later, same two tasks are running
Drop allowed CPUs to 2
3 minutes, same two tasks are running
Drop allowed CPUs to 5% (of 8 core)
3 minutes later, same two tasks running

7.14.2 ihstalled
5% of CPUs (of 8 core) are allowed
BOINC starts 1 LHC Atlas task 3 CPUs.

This last may indicate the problem. If the allowed CPUs are about 1/2 CPU, then BOINC should just not start a 3 CPU tasks at all.

Conclusions
1. There is no difference between the two versions
2. There is a difference in behavior when allow CPU is dropped between native tasks and VBox multi-threaded tasks.
3. IMHO, both versions are wrong. When allowed nCPUs is dropped, BOINC should shed load accordingly.
4. BOINC should not start tasks that would place usage above the allowed nCPUs

---

There is a mistake at the end of my last post It should be

7.14.2
Allowed CPUs 5% (of 8)
BOINC starts 1 LHC Atlas task (3 CPUS), and 1 LHC Theory tasks (3 CPU)


If BOINC will run 6 CPUs of work while the allowed CPU usage is set to less than 1/2 CPU, then the CPU limit means nothing.

++PLS

---

As far as I can tell, and from what I've read in various BOINC project fora, BOINC sometimes (always?) ignores "Switch between tasks every N minutes" and makes its own decisions based on many things, eg, deadline, project, CPU speed, etc. Mine is currently running SETI due in 2019, and I can't seem to make it switch to Rosetta due in a few days, no matter how many minutes I enter for the switch. I do trust that it will get Rosetta done in time. But I wonder: Is there some other setting I've made that prevents project/task switching? Do you readers have any hints? Thanks.

"Switch between tasks every N minutes" isn't an instruction, it's a permission.

The actual decision will be made on priority (the successor to the old debt mechanism, which divvied up resource share according to time run (only)). The new 'priority' mechanism attempts to make resource share follow the credit that would be awarded, if credit was awarded fairly by all projects according to the cobblestone definition. Which it isn't, so don't even think about it.

If the priorities have shifted enough that another project needs to take its turn, the switch will be made when one of the now-lower priority projects has reached its TSI (or a multiple thereof).

https://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen

Thanks, Richard, that explains the confusion I read about the subject. Then again, "permission" is exactly what "BOINC may switch between them this often" means.

Seti@Home with usage limits of 1% CPU and 1% of CPU Time. I started at 25 % and kept reducing down from the default 12 cores running one task each that were allocated. With that much work, my fan runs non-stop. Goal is to keep things cool and fan off. With 1% I'm down to 3 concurrent tasks. I want to get it to one task at a time. But BOINC 7.14.2 (x64) continues to run 3 tasks at a time. The manual seems clear. What am I missing?

---

There's a Robert Petersen at SETI who owns host 8620508. That machine does have 12 CPU cores - but it also has both an NVidia GPU and an Intel GPU. All three devices show tasks in the current task list.

If that's you, could you confirm that all three of the current tasks are running on the CPU only, or could there, perhaps, be one running on each device?

If two tasks are running on GPUs, try suspending GPU computation, and see if that brings the count down to one - and if it stops the fans running?

It's hard to tell from the technical specifications whether those devices are running in a full-size, well-ventilated computer case - or are all crammed into a workstation-class laptop. Cooling the latter is always problematic, but a full case with a properly-specified cooling system should be near silent even at full power.

Dropping back to 7.10.3 fixes the "Suspend when non-BOINC CPU usage" bug in 7.14.2 on MacOS 10.13.6. I haven't tried intermediate versions.