http://yafu.dyndns.org/yafu/forum_thread.php?id=106

Has this been brought up before? Is there a solution (other than running the MT tasks in a VM)?

---

Reno, NV
Team: SETI.USA

Nothing?

---

Reno, NV
Team: SETI.USA

As far as I know, it's normal. With any MT application, it'll wait until all CPU cores are available. As long as part of any core is in use with another application, the MT app won't start.

The solution might be to set 'On multiprocessors, use one core less than your maximum, so it can cater for the GPU AND run in the MT app. Not sure if that would work, but you can try.

Of course, if you feel that the working is wrong, post to the alpha or development email list. That's the quickest way to the developers.

---

As far as I know, it's normal. With any MT application, it'll wait until all CPU cores are available. As long as part of any core is in use with another application, the MT app won't start.

The solution might be to set 'On multiprocessors, use one core less than your maximum, so it can cater for the GPU AND run in the MT app. Not sure if that would work, but you can try.

Of course, if you feel that the working is wrong, post to the alpha or development email list. That's the quickest way to the developers.

Not quite. I was running AQUA's MT tasks OK with a GPU task alongside - though of course many BONCs have come and gone since AQUA folded, so that isn't current news.

I think the clue is in the linked thread - running two GPU tasks at 0.7 CPUs each, so the total CPU reservation is more than one whole CPU - I think that's the point where the MT get blocked.

Running one GPU task at a time would be worth a test: if that works, wrapping the GPU app in an app_info that only claims 0.49 <ncpus> might allow two to run - that doesn't change the way the apps run in any way, just fools the scheduler.