I would like to be able to select single threaded or mt apps.

Run only the selected applications

MilkyWay@Home:
MilkyWay@Home N-Body Simulation:
Milkyway@Home Separation:
Milkyway@Home Separation (Modified Fit):

I have a queued MilkyWay@Home N-Body Simulation 1.18 (mt) WU that has an estimated run time of 1 second. Another such WU has an expected runtime of 4seconds. A non-mt WU has an estimated runtime of 93min. In theory these small estimates could cause work buffer/cache problems.

---

I'm not quite sure what you're driving at here.

From looking at your hosts it would appear you have them set to do CPU tasks only. So if all you want is to run is MT tasks, then just deselect all the other apps except nBody for the venue you run your hosts on from the MilkyWay Preferences page. It's the only one which is CPU multi-threaded.

Unless someone just got the names messed up, the MilkyWay@Home N-Body Simulation app actually comprises both a 1.18 version (for single threaded work) and a 1.18 (mt) version.

For example,
516676632 393362221 526247 4 Jul 2013, 23:25:30 UTC 5 Jul 2013, 2:07:22 UTC Completed, validation inconclusive 1,107.82 1,077.48 pending MilkyWay@Home N-Body Simulation v1.18
516676213 393361913 526247 4 Jul 2013, 23:24:23 UTC 5 Jul 2013, 2:07:22 UTC Completed, validation inconclusive 1,380.42 3,947.34 pending MilkyWay@Home N-Body Simulation v1.18 (mt)

I would like to create a profile and be able to choose v1.18 (mt) for systems without a GPU, and the v1.18 type of WU for systems with a GPU. Maybe mt is a work in progress and not worth pursuing or maybe others would want this too?


The estimated runtime is still (didn't auto-adjust) 1sec for mt work.

---

The app is exactly the same in both cases (ie compiled against openMP), and IMHO it is a configuration error on the project side to have it assigned to the default plan_class (single threaded) for the reasons listed here.

If they wanted to run it on single core CPUs, they could do that by just spec'ing out the minimum number of CPUs as 1 in the MT plan_class for the app (the BOINC default is 2).

To do what you want requires you to run MW under the anonymous platform due to limitations in BOINC at this point.

As far as getting the runtime estimates to update, you're just going to have to wait until you run enough tasks for the APR to take effect on late model CC's.

OK but you could also separate the N-Body Simulations into mt and non-mt runs with different selectable queues, so ordinary crunchers can easily configure what they crunch.

The other alternative is running a second instance of Boinc, either in the same OS (different directory...) or in a Linux VM, with limited cores and no GPU - but again, not for the novice.

As for trying to fool the scheduler, its already bamboozled.

The devs need to respect that people who spend several $hundred on a GPU want to use it, and don't want it sitting idle just so an additional CPU thread/core gets occupied, especially when its running the same type of WU, but 100times slower. This even happens when non-mt apps are unnecessarily prioritized (mostly dual GPU setups).

Maybe the runtime estimator isn't working - after 30 mt runs it should be more than 1s. It should even adjust for queued WU's on completion of runs. 1s is probably a default because an estimate isn't being set. This won't be helping the work buffer or scheduler.

---

While we are wishing for changes, I wish we could select the number of threads the MT app will use.

I have one PC that runs 16 threads. I would be glad to give an MT task 8-12 threads, but I would like to be able to reserve a few threads for GPU tasks and whatever else I want to run.

Well, I think the point here is the project never intended nBody to run as a single threaded application. IIRC, the rationale for it is it's a simulation which is better suited to the capabilities of SMT capable processors and/or not easily or efficiently 'ported' to the type of parallelism you get with GPU's.

However the real problem is the default plan_class explicitly tells BOINC the application is single threaded, and thus it assumes all tasks running on it are going to use one core only and schedules work at both ends accordingly. Therefore, strictly speaking, a multi-threaded application should never be assigned to it, period.

Regarding the project side scheduler, yeah every project needs to tailor it to their specific requirements. Given the moving target BOINC is, I would imagine it can be just about as aggravating to get right as getting your science apps to do just what you want them to (and a lot less fun). :-D

As far as your RT estimates go, I'm not sure what the issue is on your host. I don't have many onboard my hosts at the moment, but the one which does have some is showing estimates of 4 to 7 minutes for the ones which are ready to start. This is in the ballpark based on the completed ones it has showing. So it looks like there is a bit of a mystery going on for your host. ;-)