I'm running Boinc 7.0.64(x64) on two machines, one Win 7 and the other Win 8, both with 8 cores.

What I've noticed is that when the next task that BOINC wants to start is one that needs multiple cores, no other tasks will start. Normally that's OK because in an hour or so when other tasks finish, the new task should get it (although it seems like this could be managed better).

It's a bigger problem though if you have a long running task which is getting priority due to the deadline. I had a Primegrid task the other day which was in priority state with several days to go. Since the next task in the queue wanted all 8 cores, 7 were sitting idle. I got around it by suspending the waiting task until the Primegrid task finished.

Is there a better way?

A multi-threaded task asking for 8 [or "all allowed for BOINC to use" as is the definition] is how it works. If then 1 thread is used uninterruptedly by the process and the others sit idle, it's because with some of these SMP tasks, there is not really continuous processing stream on all threads, be it on a 2-4-8 core device... it's more like on-demand. Could this be done better is not a question for the BOINC client developers, but rather for the issuers of the science application. Do they really need an SMP setup for a task that rarely/sporadic needs secondary processes... do they really need 8, and could contend with 2, but less than 8? I don't know, but if these tasks run as well on a 2 core or a 4 core as on an 8 core, then, by Jove, I'd not run them on an 8 core.

In past a feature was requested [config or preference], so you could specify how many threads an SMP was allowed to use. My understanding is that some hackathon exists to place a control in some file, but don't ask me how/where and if it works for all.

P.S. Not sure, but think that for those that are credit minded, the factor 8 is likely applied, i.e. idle or not, you get credit for 8 cores time 'reserved' so to speak. If the same credit is given for a result, were it run on a 2, 4 or 8 core, then another reason to not permit these to run on larger devices. But, if assigned to an 8 core makes them run in half the time of a 4 core, then it would be fair [IMO]

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Thanks for your response, SekeRob2.

It seems like it ought to be possible for the scheduler to look ahead a bit and see what I see. If one processor is going to be busy for a very long time (days in this case), then why not make the mult-core WU wait until the impact of idle cores would be lower?

I guess my inability to answer that question is why I'm not a developer. :-)

BTW, the question wasn't prompted by loss of credits per se. Credits are a fun way to see how much work I'm getting done but not an end in itself.

Thanks again.