Just looked at my settings trying to find an opt out for the multithreaded wu's. couldn't find it. Where is it?

Just looked at my settings trying to find an opt out for the multithreaded wu's. couldn't find it. Where is it?

I just looked at te type of units you have selected under Your Account, Milky Wy @home preferences this is the kind of unit you are running:
MilkyWay@Home N-Body Simulation v1.42 (mt)

The solution is too uncheck that kind of unit and then you won't get them anymore. So in your case uncheck the 'N-body' units.

Okay, done. I had assumed that multithreading would be a project wide setting, and hence, was looking in the wrong place.

For the curious, I wanted to get out of mt because it waste significant resources - I hate to see the Windows Idle Process "running" when I have loads of work for other projects waiting on the same machine. I dumped LHC's T4T project for the same reason.

Okay, done. I had assumed that multithreading would be a project wide setting, and hence, was looking in the wrong place.

For the curious, I wanted to get out of mt because it waste significant resources - I hate to see the Windows Idle Process "running" when I have loads of work for other projects waiting on the same machine. I dumped LHC's T4T project for the same reason.

It doesn't really 'waste' them it just uses all your cpu cores for a single unit, making it crunch faster, than if it only used a single core and took much longer. But yes it does prevent your other cores from crunching other projects too. Although unless you have a cc_config file you could still end up crunching 4 MW units and none of the other projects units.

Okay, done. I had assumed that multithreading would be a project wide setting, and hence, was looking in the wrong place.

For the curious, I wanted to get out of mt because it waste significant resources - I hate to see the Windows Idle Process "running" when I have loads of work for other projects waiting on the same machine. I dumped LHC's T4T project for the same reason.

It doesn't really 'waste' them it just uses all your cpu cores for a single unit, making it crunch faster, than if it only used a single core and took much longer. But yes it does prevent your other cores from crunching other projects too. Although unless you have a cc_config file you could still end up crunching 4 MW units and none of the other projects units.

It is not really multi-thread opt out, rather n-body opt out. If the next version of n-body is not multi-threaded, you still won't get them.

Okay, done. I had assumed that multithreading would be a project wide setting, and hence, was looking in the wrong place.

For the curious, I wanted to get out of mt because it waste significant resources - I hate to see the Windows Idle Process "running" when I have loads of work for other projects waiting on the same machine. I dumped LHC's T4T project for the same reason.

It doesn't really 'waste' them it just uses all your cpu cores for a single unit, making it crunch faster, than if it only used a single core and took much longer. But yes it does prevent your other cores from crunching other projects too. Although unless you have a cc_config file you could still end up crunching 4 MW units and none of the other projects units.

It is not really multi-thread opt out, rather n-body opt out. If the next version of n-body is not multi-threaded, you still won't get them.

GOOD POINT!!

>>> It doesn't really 'waste' them

When I see the Windows idle process running, there is computing power available that is not being used. Yes, it IS wasting them.

I too have been noticing MilkyWay nbody mt (multi-threading) v1.46 tasks... go to 100%, and then continue doing something indefinitely, utilizing only a single core, despite BOINC budgeting multiple CPUs (3, or 4, or 8) to the task. Worse yet, there are no saved checkpoints for the task!

So, yes, it is for sure leading to idle resources.

The questions are:
- Is it expected for a MilkyWay nbody mt task to continue running for a long time, single-threaded, after the 100% mark? This is wasting resources.
- If it is expected, for how long should we wait until we consider it a bug? This is wasting resources.
- Why aren't there any checkpoints? If a user decides to suspend the workunit, and restart it, it'll restart from the very beginning again. This is wasting resources.
- Does the v1.48 app solve any of these problems, and if so, which ones?

Have I made my point? My questions deserve answers.

Recently, one of my computers stopped receiving multithreaded work units, and is instead getting one work unit per thread.
How can I persuade the server to return to sending it multithreaded work units again?

---

Go to Project Preferences and select Edit and in the "Max # of threads for each MilkyWay@home task" entry box, input the number of threads you want to use. Sounds like it is currently set to only 1 for you now.

Also select all applications, though we seem to be getting only Orbit-Fitting tasks for the past year. That search has two different apps, a single-thread app and a multi-thread app.

---

Go to Project Preferences and select Edit and in the "Max # of threads for each MilkyWay@home task" entry box, input the number of threads you want to use.

That didn't work for me. I ended up with just one single-thread work unit running.
What I had to do was reset, then detach and reattach to the project. Now I have multithreaded work units again.

---

Just looked at my settings trying to find an opt out for the multithreaded wu's. couldn't find it. Where is it?

I just looked at te type of units you have selected under Your Account, Milky Wy @home preferences this is the kind of unit you are running:
MilkyWay@Home N-Body Simulation v1.42 (mt)

The solution is too uncheck that kind of unit and then you won't get them anymore. So in your case uncheck the 'N-body' units.

Linux Containers in WSL. Once you figure it out you can dedicate how many threads (virtual CPUs) each container can use and have each container focus on a single project. You can ever pin containers to specific vCPU's so they always run their workloads on a set of cores.