Can someone explain how multicore workunits are scheduled to run? I'm currently running Milkyway@Home N-Body workunits on an 8-core machine where they peg all the cores and it seems they are treated the same as single core WUs. Most of the time the only other projects that get any work done are the GPU projects.
I'm using the 7.0.2 version on one machine and the latest stable on another and there seems to be no difference between them.

JJ

So apparently this is a mystery no-one knows the answer to :-)

Still, to clarify my question:
Say I'm running two projects with equal resource shares whose WUs take the same amount of time, but project A's WUs are singlecore and project B's multicore. If the multicore uses all 8 cores and BOINC decides to download ten new WU's, in my opinion, the distribution should be around 8/2 while it seems to be an even 5/5 split. This becomes especially problematic with projects like T4T that don't allow WUs to be queued.

Of course multicore WUs are rare. I personally don't know any other project than Milkyway that uses them.

JJ

The hypothetical is basically an extremely simplified version of my situation. There have been times when my machines have been totally saturated with Milkyway n-body WUs until the project has gone down, which it has a habit of doing. At the moment the situation seems to be more equal and the only change is that the project updated the n-body application. This however shouldn't affect the scheduling which is handled by the core client.

I do admit that there might be observational bias, but was hoping that someone could give me a simple yes or no for specialized multicore scheduling in the BOINC client. My interest is mostly academical since my machines are happily crunching away, but having already delved rather deep into the configuration options I was wondering if there was some setting that could affect the situation.

JJ

WCG Techs early this week voiced that they're thinking of SMP enabled science apps, for one main purpose... to reduce the amount of memory used by BOINC on ever increasing number of cores on devices. They also made it clear that the science application must have been developed with that method in mind.

What would be nice with that is that the number of concurrent cores can be set, at project / science app level. This has been briefly discussed on these forums and the trick book seems to make it possible. Obviously we don't want volunteers to have to use trick books and file hacks... one way to chase off the largest body of volunteers.

--//--