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.