I took all of your suggestions. Let us see what happens. I was not unhappy before. I hope I continue to have good results and do not become unhappy.

I have a question. I have cut down to four projects. Suppose I want to swap out a project and add a different project. How do I be sure to not let a new project screw things up?

Thanks.

---

Please check out my blog
http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

I have a question. I have cut down to four projects. Suppose I want to swap out a project and add a different project. How do I be sure to not let a new project screw things up?

By keeping the WU cache small. There were already some suggestions, my (for your case) would be something in the range of "Store at least 0.05-0.15 days of work" and "Store up to an additional 0 days of work". Start low and increase by 0.01-0.02 if needed. Setting the last one to 0 is important IMHO as it prevents a project reporting a task to request new work on that scheduler request and fill up the cache even if another project should actually request new work to respect your ressource share settings. Also you don't need to remove any projects in the future if the client fetches too much work for them "by accident", just set them to "no new tasks" to fix the issue.

---

.

I took all of your suggestions. Let us see what happens. I was not unhappy before. I hope I continue to have good results and do not become unhappy.

I have a question. I have cut down to four projects. Suppose I want to swap out a project and add a different project. How do I be sure to not let a new project screw things up?

Thanks

This is a good question.
It's such a good question, Grant and Greg and Link have already answered/accounted for it, but in such a way that you couldn't reasonably relate to it, so let me try to address that.

I think the real answer is that if you want to join any new project (or maybe reinstate one of the ones you just removed) as long as it doesn't have a shorter deadline than Rosetta's 3 days, it won't matter too much because the Boinc Manager is at its best when juggling multiple projects.
You could even <add> the new one to the 4 you have remaining without taking one out - up to you.

But Boinc does seem to have an <initial> problem with newly added projects and we've sometimes seen it over-commit to calling for tasks until it gets some experience of how quickly you process and return them.
And the solution to this is to not give Boinc too much scope to over-call tasks down.

So again we're back to the settings on the Computing tab under Computing Preferences.

I wasn't quite accurate with what I wrote previously.
I only run 2 active projects (if you can call them 'active' recently) - Rosetta and WCG

On my 16-core machine I have it set at...
Store at least 0.50 days and up to an additional 1.00 days of work
...because they get blasted through so quickly compared to their deadlines it never becomes an issue

But I also have a 6-core i5-9600 where the numbers I use are 0.1 and 0.5 because it's much slower ploughing through tasks and I like to give Boinc some margin to play with.

If I was running 4 or 5 projects, I would definitely be using 0.1 and 0.5, first so that Boinc can juggle them comfortably and second so Boinc can't get carried away calling for tasks, especially when a new project gets added.
These aren't as tight settings as Grant or Link suggest, but it's a reasonably pragmatic compromise from the settings you originally had, which were 0 and 3.0.
You'd be planning to succeed, not planning to fail.

And now I've remembered one other setting that's particularly relevant when you have a lot of different projects running at the same time.
Switch between tasks every xxx minutes
I seem to recall the Boinc default is particularly low such that, if some projects offer long-running tasks, Boinc can switch away from them before they're finished, then struggle to get back to them before their deadline.
I personally use 999 minutes (16+ hrs), but you could just as well use 9999 - essentially, a sufficiently large number that Boinc doesn't switch away from a task before it's completed.

Neither of these suggestions affect how your tasks run - they just ensure your varied projects sit well together and you complete everything before deadline - the latter being a hidden problem you had at the start of this thread.

Note: I've now completely run out of things that barely make any difference.
Which means the next thing I'm going to suggest will start to make a huge difference to how well your tasks run...
...while simultaneously making no difference you can notice, because everything else is set up so well.

Actually, that's not quite true. You may notice tasks being returned twice as fast because they've already done all their work in half the time, which will enable Boinc to juggle all your projects much better as well.
But I'll still take it slowly, and explain it clearly so you can maintain confidence that any change suggested is going to be a help and not a risky change in any way.

---

would definitely be using 0.1 and 0.5

You are always better off using the "Store at least xx days of work" value to set the cache size. Making use of the "Store up to an additional xx days of work" results in unexpected behaviour.

This is because "Store at least xx days of work" is the size of the cache that it maintains. "Store up to an additional xx days of work" is exactly that- additional days of work on top of the actual cache value (which is set by "Store at least xx days of work").

0.5 and 0.1 will result in a cache of very close to 0.5 days of work. As work is completed, it will top up the cache up to meet the 0.5 day setting. The amount of work in the cache will generally be around 0.5 days.
0.1 and 0.5 results in the cache running down to less than 0.1 days of work, before then refilling itself to 0.1 plus the additional 0.5 days worth. The amount of work in the cache will vary between 0.6 days & less than 0.1.

---

Grant
Darwin NT

0.1 and 0.5 results in the cache running down to less than 0.1 days of work, before then refilling itself to 0.1 plus the additional 0.5 days worth. The amount of work in the cache will vary between 0.6 days & less than 0.1.

Well, that depends on how long the WUs are running, so basically on the projects you run. Current versions of BOINC report completed tasks latest one hour after uploading the result files, so after about 0.042 days.

So if you run a project with short tasks (<1h), with this cache settings BOINC will contact the project servers about once an hour to report the completed tasks and will piggyback a request for new tasks on that scheduler request. So (assuming a project with steady work supply) your chache will be somewhere between around 0.55 and a bit (max. the length of one WU) over 0.6 days.

With modern CPUs with many cores (i.e. 8+), even if running longer tasks, there's nearly always a task, that has been finshed in the past hour and that's where the issues start when running more than 1 or 2 projects simultaneously, in particular if the run times on their WUs are different enough. The project with shortest tasks will always have something to report and will always fill up the cache when reporting, projects with longer tasks will have simply less chances to ask for new work. So over time the project with shortest tasks might push out all other projects, in particular if they don't have an absolutely steady WU supply. That's why Richard could never get automatically any work for Rosetta, his 0 days cache was filled with up to 3 days of work from other projects, so why should BOINC ask for work from Rosetta?

So if he wants to run 4 or more projects simultaneously, which is in general nothing wrong, I think the best results he will get with 0 additional days (once everything settles down), as that eliminates any piggybacking of requests for new work on scheduler requests to report completed tasks, so BOINC will always make separate request for work and when doing that, choose exactly the project that should get more work to respect the ressource setttings.

---

.

So if he wants to run 4 or more projects simultaneously, which is in general nothing wrong, I think the best results he will get with 0 additional days (once everything settles down), as that eliminates any piggybacking of requests for new work on scheduler requests to report completed tasks, so BOINC will always make separate request for work and when doing that, choose exactly the project that should get more work to respect the ressource setttings.

My machine has 16 cores, but I currently allow only 13 for Boinc work. I have 128 GBytes of RAM, and 450 GBytes of disk allocated to Boinc client. I am running ClimatePrediction, WCG (all 5 tasks), Denis, Rosetta, and Einstein. Settings are for 1 days work and 1 day additional.

Trouble is that none of them have any work to supply and my machine is running only 4 tasks. 2 Einstein and 2 Rosetta.

I am beginning to think that WCG is completely mismanaged and has been for two years or so. Of their 5 "active" projects. only MCM1 ever delivers work, and I have none. CPDN has supplied me no work since last June. Denis supplies work only about once a week, and I cannot allow a week's worth of work from them because their deadline is only about 3 days.

My guess is that other than server mismanagement, researchers are just using less and less distributed computing, even though free, and running on large local computing systems. And as these large local systems get larger, faster, and cheaper, the whole Boinc system will just wither away.

---

Trouble is that none of them have any work to supply and my machine is running only 4 tasks. 2 Einstein and 2 Rosetta.

Einstein has lots of work, both FGRP5 and BRP4G, and should easily use all your cores.

WCG should have lots of MCM1 work and some OPNG work sometimes (the other projects are suspended), but they simply do not have staff capable of running a BOINC project properly, the reliability of their cloud environment is disastrous and the communication with the so called "tech team" is painfully slow. The fact, that they got highly fu... modified BOINC environment from IBM propably doesn't help either.

There are however far more projects than those four you mentioned doing a real science, so perhaps you should try to find one or two more as basically you have only one reliable project in your list (Einstein). Milkyway, which you have crunched for in the past, is doing pretty well recently if you don't mind multithreaded WUs.

---

.

0.1 and 0.5 results in the cache running down to less than 0.1 days of work, before then refilling itself to 0.1 plus the additional 0.5 days worth. The amount of work in the cache will vary between 0.6 days & less than 0.1.

Well, that depends on how long the WUs are running, so basically on the projects you run. Current versions of BOINC report completed tasks latest one hour after uploading the result files, so after about 0.042 days.

So if you run a project with short tasks (<1h), with this cache settings BOINC will contact the project servers about once an hour to report the completed tasks and will piggyback a request for new tasks on that scheduler request. So (assuming a project with steady work supply) your cache will be somewhere between around 0.55 and a bit (max. the length of one WU) over 0.6 days.

With modern CPUs with many cores (i.e. 8+), even if running longer tasks, there's nearly always a task, that has been finished in the past hour and that's where the issues start when running more than 1 or 2 projects simultaneously, in particular if the run times on their WUs are different enough. The project with shortest tasks will always have something to report and will always fill up the cache when reporting, projects with longer tasks will have simply less chances to ask for new work. So over time the project with shortest tasks might push out all other projects, in particular if they don't have an absolutely steady WU supply. That's why Richard could never get automatically any work for Rosetta, his 0 days cache was filled with up to 3 days of work from other projects, so why should BOINC ask for work from Rosetta?

So if he wants to run 4 or more projects simultaneously, which is in general nothing wrong, I think the best results he will get with 0 additional days (once everything settles down), as that eliminates any piggybacking of requests for new work on scheduler requests to report completed tasks, so BOINC will always make separate request for work and when doing that, choose exactly the project that should get more work to respect the resource settings.

Two interesting posts, both of which have taught me something as I hadn't thought enough about them before.
I think that's because, between Rosetta and WCG, the former has longer-running 8hr tasks with a short 3-day deadline, while the latter has shorter 1h30m tasks with a longer 7-day deadline.

So Grant is saying, instead of setting 0.1 + 0.5 days of cache, the setting should be 0.5 + 0.1 days
And Link is saying, in a multi-project environment like Richard has, the setting would be safer and more reliable as 0.5 + 0.0 days

A subtle difference, but more reliable and certain that Boinc doesn't run away with itself, as it sometimes can, especially when new projects are added and task--runtime is initially unknown to Boinc.
I take the points made.

---

Trouble is that none of them have any work to supply and my machine is running only 4 tasks. 2 Einstein and 2 Rosetta.

Einstein has lots of work, both FGRP5 and BRP4G, and should easily use all your cores.

WCG should have lots of MCM1 work and some OPNG work sometimes (the other projects are suspended), but they simply do not have staff capable of running a BOINC project properly, the reliability of their cloud environment is disastrous and the communication with the so-called "tech team" is painfully slow. The fact, that they got highly fu... modified BOINC environment from IBM probably doesn't help either.

I've been very critical of WCG privately, but it seems that if it wasn't taken on by the current people it would have disappeared altogether, so while not being happy at all with it, and very frustrated, even a badly running WCG is better than no WCG at all, which I think is the only other realistic alternative. I wouldn't like that as it enables projects to offer work out that they probably don't have the resources to set up independently.
I'm sure no-one's entirely satisfied with the situation we find ourselves in.

---

I've been very critical of WCG privately, but it seems that if it wasn't taken on by the current people it would have disappeared altogether, so while not being happy at all with it, and very frustrated, even a badly running WCG is better than no WCG at all

Sure, it's better, but still very frustrating and I don't see how they could possibly offer any new projects in the foreseeable future, their setup is breaking down with MCM running alone and what's worse, they don't know, why something is breaking and how to get it running again. I mean, they have now been working two weeks (!) on getting MCM work generators to work properly again and they still didn't succeed and the plans on how to resolve the issue posted by TigerLily read like "we don't know why something, that worked for several weeks, suddenly stopped working but we will be poking in the dark and hopefully hit the right thing".

---

.

There are however far more projects than those four you mentioned doing a real science, so perhaps you should try to find one or two more as basically you have only one reliable project in your list (Einstein). Milkyway, which you have crunched for in the past, is doing pretty well recently if you don't mind multithreaded WUs.

I ran some project that did multithreaded work. IIRC it ran four threads at a time. But it confused my Boinc client and OS ( forget the details) . So I stopped taking those. And some project does multithreaded tasks but I have to set up a special environment for it and I am not willing to do that.

Ages ago, I was running Seti@home, ClimatePrediction, WCG, and Malaria. I know Seti@home quit, followed by Malaria. But at the time they provided plenty of work for the computers I was running. One had two hyperthreaded Xeon processors.

I added Rosetta at some point to keep the work up. Most recently I added Universe and MilkyWay. These did not interest me all that much. One of them now sends out only GPU work; the other's manager died and is sending out no more work.

If CPDN ever starts sending out Linux work (tasks usually take a week or so to run), and if WCG ever get their act together, I should be fine.

---

A progress report card for Richard

This thread was started on 6th March and the first post of settings was on 9th March.
Since then we've worked on a lot of very, very minor settings that probably changed nothing in terms of processing time (<1% is my guess) but made lots of progress in terms of being able to download tasks at all, run them successfully (after a fashion) and return them before each project's deadline to receive credit.

What actual difference has this made? Any?

There's a stats site for users running Boinc projects called Boincstats (notably excludes folding@home)
Here are links to Richard's Boincstats pages, where the 3rd chart down shows daily credit for each of his 4 current projects.
Look at the figures in the week up to 9th March and then the credit since

Numberfields
The same or a little better

Einstein
Probably doubled

Rosetta
From nothing at all to loads

Milky Way
From nothing at all to loads

All pluses, no minuses.

There's also a kind of Boinstats home page that shows progress at all projects at once where you can see how things have gone in the last day, week and month and a world positions compared to all other contributors in each project (and a total for all Boinc at the top). 193,000 place improvement at Rosetta and 38,000 place improvement at Milky Way are the standouts.
Boincstats - Richard Mitnick
It's going gangbusters! And we haven't even done anything yet!

To emphasise, I don't think your PC is any more productive than it was before (up to 1% maybe) but tasks are being downloaded in the first place, run to completion and returned before deadline so they're usable by each project.
Prior to this, failure to return tasks on time <may> have meant your PC's work was discarded if it didn't receive credit.

Congratulations Richard. Good work.

---

The main thing I take from this is “Try the suggestions” - you can always reverse the config changes if they don’t work.

First, thanks. I got a lot of needed help.

You know, there are many people who would like to contribute to all kinds of science projects and BOINC is perfect for this. But many of us are simpletons when it comes to dealing with the intricacies of the process. It is just easier to go to Folding@home where there is nothing to do but install the process. And I did that. But Folding is only medical/biological and BOINC is so much more.

Second, thanks for the link to my page at BOINCStats. I could never find it myself.

---

Please check out my blog
http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

You know, there are many people who would like to contribute to all kinds of science projects and BOINC is perfect for this. But many of us are simpletons when it comes to dealing with the intricacies of the process. It is just easier to go to Folding@home where there is nothing to do but install the process. And I did that. But Folding is only medical/biological and BOINC is so much more.

I kind of mentioned something about this earlier on.
Seti was the original project and people over there were the most experienced, most technically-minded, heavily into fine-tuning their PCs and Boinc settings and had the biggest farm of rigs anywhere, but when Seti closed down and they arrived at Rosetta in their droves, all their expertise seemed to be based on assumptions that one project was much the same as another, not appreciating the differences here, and Rosetta virtually collapsed in many and varied ways you wouldn't believe. It's not a case of being a simpleton or a genius, a wiz or a novice, there's certainly no intended disparagement or condescension. It's more a case of these are all the conclusions we drew from all our own personal mistakes so you don't have to suffer them for as long as we did.

One thing this thread has shown is that baldly and curtly telling someone what to do without explaining why won't get results, while working through the 'why' makes it more coherent.
It's classic "Give a man a fish and he'll eat for a day. Teach a man how to fish and he eats for a lifetime' stuff.

We've only dealt with background stuff up to now.
We started with your PC running badly and unsuccessfully and reached the stage where your PC is running badly (oh so badly) but successfully.
So now I think it's time to get <really> productive, but again just one stage at a time, verifying there are no downsides to any change before moving any further.
As Bryn has astutely pointed out "The main thing I take from this is “Try the suggestions” - you can always reverse the config changes if they don’t work."

First, I'll mention something I don't want you to change.
On the Computing tab of Options/Computing Preferences, both in the section 'When Computer is in use' and 'When Computer is not in use' you've set 'Use at most 50% of the CPUs'
The majority of us have this set to 100%, but there's no law that says you have to - it's entirely up to you and no-one can tell you different, so I'm not going to.
In fact, if you do any GPU processing, those GPU tasks need a little CPU support, so not setting it right up at 100% is a good choice (I've just grabbed some WCG GPU tasks and if you ever rejoin GPUGRID this will apply all the more).

You can tell this is working on your PC as it's capable of running 16 tasks at the same time, but you're only running 8 at a time. All good - that's fine and settled.

BUT
the rest of that line on the Computing tab says 'and at most 50% of CPU time'

Now, if you're anything like me, you might take that to mean it's running at a leisurely half-speed. Cruising along comfortably like you might in your car.
If only that were true.

Many years ago, in the days of Windows 8 I seem to remember, there was a nice little Boinc Resource utility that showed how each core/thread was running.
And, naturally, I thought it would show each thread running at whatever level I had it at (80% I think).
But it didn't.
What it showed was that each core was running at 100% for (in my case) 80% of the time and 0% 20% of the time (50% each in your case).
On and off and on and off multiple times <every second>! Hundreds of times per minute, thousands of times per hour, tens of thousands of times per day!
I don't know about you, but I don't drive my car like that. Imagine if you did!

This is all kinds of crazy imo.
While I'm absolutely certain my car wouldn't appreciate that, I don't really know if a CPU wouldn't like it in the same way, but I'm also not sure it's your intention that should happen either.

But that's not the point I really want to make. The point is that it's massively, Massively, MASSIVELY inefficient for how your tasks run and I'll show you why/how much.

In your last post here, right-click your name and 'open link in new tab'. Click 'View' next to Computers in the header, click 'tasks' under Computer ID, finally click 'Valid' in that header area.
You'll now see a list of your completed Rosetta tasks.
Look at the columns 'Run time (sec)' and 'CPU time (sec)' for each task and compare them.

We often call "Run time" wall-clock time. It's the amount of real time from starting the task it took to complete, in seconds. For reference, 8 hours is 28,800 seconds and you've got tasks taking 24,000 to 30,000 seconds
"CPU time" is the amount of time your computer actually did any work and they're all about 10,800 seconds, which is 3 hours.
Meaning that for 5 hours out of ~8 hours you thought your PC was working on its tasks, it was actually doing nothing at all.

This is what the setting 'at most 50% of CPU time' is resulting in, not just all that stop/starting business I was on about earlier, weird as that may be.
This is objectively bad/terrible/disastrous and is the reason people have been saying bad things about how your PC is running from the start of this thread, even if you did say you were happy with it.

Now, one thing that people can get <legitimately> concerned about is Boinc taking over your PC, overstressing itself by running hot and bogging down your PC by things like mouse movement being jerky, videos stuttering and stuff like that. And there's some truth to that. If you notice any signs of those kinds of things happening, you certainly should ease back.

BUT
PCs are built to withstand quite a lot in the first place. If you have a 4 or 6 or 8-core PC, it's built to handle them being utilised.
And you have a particular advantage, because of a decision you've already made, in that you've already chosen to only use 50% of your CPU threads, which we've already said you shouldn't change.

50% of cores/threads at 50% utilisation means your PC is set to run at 25% of its capability
And the fact you're only achieving about 3/8ths utilisation means your PC is running at less than 20% of its capability
Meaning that you're a <million miles> away from any possibility of running into any of those quite legitimate concerns.

So, here comes the one very simple change I want you to make that's going to make a helluva difference to your Boinc performance, not just with Rosetta (where I notice we've just run out of new tasks) but with <ALL> the projects you run.

And because I don't want to take any risk of jumping ahead, it'll be a change in one area only.

In the section of the Computing tab marked 'When computer is <NOT> in use' only
Where it says 'and at most 50% of CPU time' - change that directly to 100%

That's it. A 10 second job.

You're a million miles from any problem that might ever be associated with this change and, because it's when you're not even using your computer, the only possible result (and I doubt this will happen, but it might) the only way you might notice something has changed is that the PCs cooling fans may become active so you can hear them while not using your PC. Not to the extent that it harms your PC in any way, because it's what they're there for, but depending on where you keep your PC it might rise above the ambient sound levels you're used to. And that would be because it's doing the work you already decided you want it to do.

Or you may notice nothing at all, which is what I anticipate.
But you're the only arbiter, so it's entirely up to you choose, not me or anyone else here.

Oh, and your PC Boinc performance will double off the back of this.
And your tasks on all your projects will complete twice as fast.
And your Boincstats credits will double.
And if you choose to add back any more Boinc projects, you'll have more space to do so without changing any more settings, because they're already ideal.
And there's still a couple more changes to make to improve further, because I've nearly (but not quite) covered everything in this ridiculously long post (but you're used to that by now)

I'll be very interested how this turns out - so please report back in a few days.

---

I am confused. I looked at "When computer is not in use" and CPU usage is already set at 100%, as it is also in "When computer is in use".
Please clarify.

Thanks.

---

Please check out my blog
http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

Take a look at the log in the Boinc Manager (CTRL + SHIFT + E) Look for Preferences and where it is taking them from. They can be set locally in Boinc Mgr or on the individual project website preferences. I posted my example below. You can see is is shows it's from the Einstein@Home right before it mentions the Preferences settings. Visit all your projects and check the web preferences you have set. If you don't see the preferences in your log data, you can just tell Boinc Mgr to exit and shut down all tasks and then start it up again and look at the log.

I just noticed you can see where the preferences are coming from a bit quicker in Boinc Mgr by going to the Options, Computing Preferences tabs. It reports it in that window too.



2024-03-31 11:35:45 AM | | Starting BOINC client version 7.24.1 for windows_x86_64
2024-03-31 11:35:45 AM | | log flags: file_xfer, sched_ops, task
2024-03-31 11:35:45 AM | | Libraries: libcurl/8.2.1-DEV Schannel zlib/1.2.13
2024-03-31 11:35:45 AM | | Data directory: E:ProgramDataBOINC
2024-03-31 11:35:45 AM | | Running under account Jonathan
2024-03-31 11:35:45 AM | | OpenCL: AMD/ATI GPU 0: Radeon RX 560 Series (driver version 3584.0 (PAL,HSAIL), device version OpenCL 2.0 AMD-APP (3584.0), 2048MB, 2048MB available, 2478 GFLOPS peak)
2024-03-31 11:35:45 AM | | Windows processor group 0: 8 processors
2024-03-31 11:35:45 AM | | Host name: ryzen
2024-03-31 11:35:45 AM | | Processor: 8 AuthenticAMD AMD Ryzen 7 1700 Eight-Core Processor [Family 23 Model 1 Stepping 1]
2024-03-31 11:35:45 AM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 svm sse4a osvw skinit wdt tce topx page1gb rdtscp fsgsbase bmi1 smep bmi2
2024-03-31 11:35:45 AM | | OS: Microsoft Windows 10: Professional x64 Edition, (10.00.19045.00)
2024-03-31 11:35:45 AM | | Memory: 15.91 GB physical, 18.29 GB virtual
2024-03-31 11:35:45 AM | | Disk: 223.55 GB total, 211.46 GB free
2024-03-31 11:35:45 AM | | Local time is UTC -5 hours
2024-03-31 11:35:45 AM | | No WSL found.
2024-03-31 11:35:45 AM | | VirtualBox version: 7.0.14
2024-03-31 11:35:45 AM | DENIS@home | Found app_config.xml
2024-03-31 11:35:45 AM | DENIS@home | Max 8 concurrent jobs
2024-03-31 11:35:50 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 02-Mar-2024 11:22:16)
2024-03-31 11:35:50 AM | Einstein@Home | Host location: none
2024-03-31 11:35:50 AM | Einstein@Home | General prefs: using your defaults
2024-03-31 11:35:50 AM | | Preferences:
2024-03-31 11:35:50 AM | | - When computer is in use
2024-03-31 11:35:50 AM | | - 'In use' means mouse/keyboard input in last 3.00 minutes
2024-03-31 11:35:50 AM | | - max CPUs used: 8
2024-03-31 11:35:50 AM | | - Use at most 100% of the CPU time
2024-03-31 11:35:50 AM | | - max memory usage: 12.73 GB
2024-03-31 11:35:50 AM | | - When computer is not in use
2024-03-31 11:35:50 AM | | - max CPUs used: 8
2024-03-31 11:35:50 AM | | - Use at most 100% of the CPU time
2024-03-31 11:35:50 AM | | - max memory usage: 14.32 GB
2024-03-31 11:35:50 AM | | - Leave apps in memory if not running
2024-03-31 11:35:50 AM | | - Store at least 0.10 days of work
2024-03-31 11:35:50 AM | | - Store up to an additional 0.25 days of work
2024-03-31 11:35:50 AM | | - max disk usage: 100.00 GB
2024-03-31 11:35:50 AM | | - (to change preferences, visit a project web site or select Preferences in the Manager)
2024-03-31 11:35:50 AM | | Setting up project and slot directories
2024-03-31 11:35:50 AM | | Checking active tasks

I am confused. I looked at "When computer is not in use" and CPU usage is already set at 100%, as it is also in "When computer is in use".
Please clarify.

Oh... OH!...

Well, this explains a lot, Almost the entirety of the difference between what you're seeing and what everyone else thought.

Quoting from your post on 9th March where you listed your Boinc startup settings:

3/9/2024 7:57:31 AM | | Preferences:
3/9/2024 7:57:31 AM | | - When computer is in use
3/9/2024 7:57:31 AM | | - 'In use' means mouse/keyboard input in last 1.00 minutes
3/9/2024 7:57:31 AM | | - max CPUs used: 8
3/9/2024 7:57:31 AM | | - Use at most 50% of the CPU time
3/9/2024 7:57:31 AM | | - max memory usage: 7.81 GB
3/9/2024 7:57:31 AM | | - When computer is not in use
3/9/2024 7:57:31 AM | | - max CPUs used: 8
3/9/2024 7:57:31 AM | | - Use at most 50% of the CPU time
3/9/2024 7:57:31 AM | | - max memory usage: 12.50 GB
3/9/2024 7:57:31 AM | | - Suspend if no input in last 1.00 minutes
3/9/2024 7:57:31 AM | | - Leave apps in memory if not running
3/9/2024 7:57:31 AM | | - Store at least 0.00 days of work
3/9/2024 7:57:31 AM | | - Store up to an additional 3.00 days of work
3/9/2024 7:57:31 AM | | - max disk usage: 10.00 GB
3/9/2024 7:57:31 AM | | - (to change preferences, visit a project web site or select Preferences in the Manager)

The "Max CPUs used: 8" part is the 50% figure in your "Use at most xxx% of the CPUs" which is fine
BUT if you <think> Boinc is using those 8 CPUs 100% of the time, BOINC is <actually> only using them 50% of the time, whether you're using your computer or not.

Ok, there's a straightforward way around this.
First, in the Boinc Projects tab, select Rosetta and on the left, click the "Your Account" button.
On the webpage that opens, select "Computing preferences"
Switch briefly back to Boinc, select Computing Preferences from the Options menu to see what you think you should have set, then switch between Boinc and the web page to match the two up because it looks like they're saying different things and Boinc is calling up what you've got set on the web page, <not> within the Boinc manager.

The specific relevant setting on the webpage is the 2nd one under the "Usage Limits" heading
"Use at most 100 % of CPU time"
(The first one should be 50% of the CPUs, meaning 8 cores/threads of your 16)

You need to scroll down to the "Edit Preferences" option at the bottom of the webpage to change what shows on the page.
Make the necessary changes to the webpage, then chose Update Preferences at the bottom afterwards.

Having done that, return to Boinc and, with Rosetta selected, click Update on the left.
Then bring up Options/Computing Preferences again to confirm it's still saying everything you expect it to say.

This is the belt and braces approach.
You ought to have been able to use your local (within Boinc) settings all along but now, having ensured the webpage is the same as what you've set locally, an accidental click of the wrong button won't set you back to the beginning again.

I don't know whether you should do the same with each of your other projects (as a backstop to pressing the wrong button within Boinc).
As long as the above process with Rosetta goes well, it may be worth ensuring your other projects aren't leading your settings astray in the same way.

Bottom line is you should ensure on the Computing tab within Boinc you are using "Local Prefs" and don't accidentally click to use "Web Prefs"

---

I don't know whether you should do the same with each of your other projects (as a backstop to pressing the wrong button within Boinc).
As long as the above process with Rosetta goes well, it may be worth ensuring your other projects aren't leading your settings astray in the same way.

When and how BOINC uses your computer  Computing preferences

applies to all projects.

Preferences for this project XXX  preferences

are the ones that will apply to only that project.


Web settings made on one project will propagate to all projects.
If you make different changes on different projects, the last changed settings & values will be the ones that apply to all projects.

Bottom line is you should ensure on the Computing tab within Boinc you are using "Local Prefs" and don't accidentally click to use "Web Prefs"

From Richard's last posted log.

3/9/2024 7:57:31 AM | GPUGRID | General prefs: from GPUGRID (last modified 16-Feb-2024 23:38:58)

He was using web based preferences when he started this thread.

---

Grant
Darwin NT

I don't know whether you should do the same with each of your other projects (as a backstop to pressing the wrong button within Boinc).
As long as the above process with Rosetta goes well, it may be worth ensuring your other projects aren't leading your settings astray in the same way.

Bottom line is you should ensure on the Computing tab within Boinc you are using "Local Prefs" and don't accidentally click to use "Web Prefs"

I've just taken a look at WCG web settings and, while a lot of them look like they have equivalents within Boinc's Computing settings it's not always absolutely clear, so while ensuring web page settings for each project are as close to your local settings as possible, it's best to ensure you use local Boinc prefs so everything's as familiar and controllable as possible.
Whatever avoids confusion and conflict is always preferable, especially in a multi-project environment.

---