Hey guys, long time user, first time posting on the forums. I have a Ryzen 5700g. Anyways, if BOINC spawns 16 processes to use all my cores, is each one treated like a single-threaded application? Unlike, for example, Cinebench which is 1 process.

In particular, for Ryzen there is a BIOS option for CPPC (and the related CPPC preferred cores) and these options alter how windows schedules tasks to CPU cores. I'm trying to figure out to configure more for single thread or focus on multithread performance. Let me know if there's any more info I can provide.[/quote]

Hey guys, long time user, first time posting on the forums. I have a Ryzen 5700g. Anyways, if BOINC spawns 16 processes to use all my cores, is each one treated like a single-threaded application? Unlike, for example, Cinebench which is 1 process.

Rosetta (and most, but not all) BOINC project applications are single threaded. So on a multi-core system, it will run one instance of the project's application for each task on each available core/thread.

The main limiting factor for how many Tasks you can run at a time is the amount of RAM & how much available drive space your system has, and how much of that has been made available to BOINC to use. The current Python Tasks which require VirtualBox to be installed require roughly 8GB of disk space per Task, and a minimum of 3GB of RAM in order to start (although they actually use much less).
The older (and near impossible to get any of) Rosetta 4.20 Tasks require anywhere from a couple of hundred MB up to almost 4GB of RAM, generally they are around 1GB or less. If you allow 1.3GB of RAM per Task, you won't run in to any memory issues. Storage space needed for those Tasks is only a few hundred MB each.

---

Grant
Darwin NT

Thank you sir.

It's a shame that VMs have only one core assigned.
For a task that runs on one core, it eats up a lot of RAM.
And you've got a lot of VMs running at the same time that have the exact software packages inside of themself.
The machine has 32 GB of RAM and it seems like I'd need more than that just to run 12 instances of rosetta properly.
I can't let R@H gobble up all my ram, because this starts to slow down my machine so much that I can feel it when doing everyday tasks on it.
My 12 Core Ryzen is not even under half load because of the RAM limitation.
Couldn't you add a checkbox or config option to allow a VM to have say 2 or 4 cores assigned to it ?
Imho R@H is loosing a lot of potential with the single core virtual machine approach

If Python is eating to many resources, then just make a app_config Fike with a project max line in it and restrict RAH to the amount of cores you want to give. BOINC will limit RAH and the free resources will go to the other projects.

It's a shame that VMs have only one core assigned.
For a task that runs on one core, it eats up a lot of RAM.
And you've got a lot of VMs running at the same time that have the exact software packages inside of themself.
The machine has 32 GB of RAM and it seems like I'd need more than that just to run 12 instances of rosetta properly.
I can't let R@H gobble up all my ram, because this starts to slow down my machine so much that I can feel it when doing everyday tasks on it.
My 12 Core Ryzen is not even under half load because of the RAM limitation.
Couldn't you add a checkbox or config option to allow a VM to have say 2 or 4 cores assigned to it ?
Imho R@H is loosing a lot of potential with the single core virtual machine approach

I have 64GB of RAM on my 24 thread Ryzen. Enough RAM, but it still gets sluggish with VB tasks. Ryzens don't like doing VB, same problem with LHC, multithreaded or not.

As for multithreaded Rosetta, Folding at home can multithread all 24 of my threads to 1 biology task, on Covid, Cancer, Alzheimers, anything, so it must be possible, I guess the way Rosetta did it isn't so good.

On systems with lots of cores volunteers focus on the cores and want all of them to be fully loaded but without getting a sluggish system ;-)

Believe it or not: in case of many Rosetta VMs running concurrently the I/O system is the limiting factor, mainly caused by the snapshots written every 10 min per VM.

So, you are absolutely right when you claim:
"I guess the way Rosetta did it isn't so good."

On systems with lots of cores volunteers focus on the cores and want all of them to be fully loaded but without getting a sluggish system ;-)

Believe it or not: in case of many Rosetta VMs running concurrently the I/O system is the limiting factor, mainly caused by the snapshots written every 10 min per VM.

So, you are absolutely right when you claim:
"I guess the way Rosetta did it isn't so good."

The IO is ok here as far as I can see. SSDs manage it easily, even my computers running old 1 or 2TB hard disks are keeping up. Yes, they slow down for a bit when changing tasks, but otherwise they're fine. It's just that problem with the fucking windows update ruining the VB stuff :-)

The typical answer: "My SSD is fast enough"
But a disk/SSD is just 1 component of the complete I/O system - the last in a chain.

The typical answer: "My SSD is fast enough"
But a disk/SSD is just 1 component of the complete I/O system - the last in a chain.

But the slowest part of that chain.

The typical answer: "My SSD is fast enough"
But a disk/SSD is just 1 component of the complete I/O system - the last in a chain.

But the slowest part of that chain.

As I wrote: Believe it or not
One more who doesn't believe it.
(Just to avoid unnecessary work: There's no need to reply with tons of statistics about how fast/slow each component is)

The typical answer: "My SSD is fast enough"
But a disk/SSD is just 1 component of the complete I/O system - the last in a chain.

But the slowest part of that chain.

As I wrote: Believe it or not
One more who doesn't believe it.
(Just to avoid unnecessary work: There's no need to reply with tons of statistics about how fast/slow each component is)

What is it you don't like in Rosetta VB? Theory and CMS in LHC are also single core. And what do I not believe? You said Rosetta writes every 10 minutes. For how long? What percentage of the time is it doing this? And if it didn't, how much work is lost when things go wrong?