I run many projects, but this is my first one that requires VirtualBox. I don't quite know the nature of this kind of project, and I've set the multithread settings to a max of 4 CPUS. Somehow I keep on getting work that runs on 1 CPU core only. I've read some posts that hinted that the tasks uses 1/3 of the cores available(???). I've also been wondering if the VM runs separately from the other BOINC projects, like you could have a PrimeGrid PSP task running on 4 CPUs AND a Quchempedia task running while BOINC is set to run on a max of 4 cores. Also if we could multithread will we get faster runtimes? I get the idea from "server status" that the MEAN (not median) runtime is ~17hrs. What's the median and what's the possibility of it running longer or shorter? I am quite a noob at DC and have many questions.

Where in QuChemPedIA do you see the option of multi-threading?

---

i can't post screenshots, and I won't, but it says "Max CPUs per task" in prefs.

Those are your project preferences, with a 2 selected your system would crunch two WUs, one on each core.

It is not multi-threading, that is where all available cores (as set in your preferences) crunch one WU until it is complete. The app the project sends has control over that process, not you.

I see you aborted two work units, that was probably unnecessary. Was it because they showed such a long time until completion? If so, do not worry about estimated times, and are notoriously inaccurate in this project.
You may have seen in one of my previous posts that I run only one third of my available cores, two of six. Considering my cores and RAM available, that is the way I avoid the "unmanageable" notifications written about in another thread. YMMV, perhaps you can run more, or possibly less. You will need to experiment until you find the most stable configuration for your machine.

Disregard the 17 hours runtime notice, the only important average runtime is yours, that you will find for yourself. I see runtimes estimated anywhere from 22 days down to 2 hours on my machine. They almost always complete in several hours. Take a look at my computer and see for yourself. As far as running VirtualBox, install in on your computer and forget about it, the project app makes all necessary settings.

---

I did Pause the BOINC Client and then Exit the Client.
I started up vBox and change the CPU from 1 to 4 and it is running but still shows 6+ Days to complete.

This seems to off worked less than 3 Hours to complete.
I also changed the Memory to 2048
Run time 2 hours 58 min 13 sec
CPU time 2 hours 56 min 43 sec
https://quchempedia.univ-angers.fr/athome/result.php?resultid=81121


But we need to be able to Set Setting CPU Count for VM. (1) to Setting CPU Count for VM. (#)
# the number of Cores or Threads we want to run

Going to Test the Defaults to compare runtimes on an AVX-512 Rig
Some Tasks did fail (Validate error) on startup but that seems to be the norm for vBox Tasks

Thank you!

Sorry for reviving an old thread. But the issue at hand is still applicable, so here we go:

dannyridel wrote:

I've set the multithread settings to a max of 4 CPUS. Somehow I keep on getting work that runs on 1 CPU core only.

Check the apps.php page, i.e. "Computing -> Applications" at the top of the web page. At this time, this hints that

the "NWChem" application is single-thread,
the "NWChem long" application is single-threaded on Windows,
the "NWChem long" application is currently single-threaded on Linux unless "Run test applications?" is switched to Yes at the project preferences, until the 2t/ 4t/ 8t versions are promoted out of beta status.

At least that's how I understand it.

* * * Wish list * * *

1. Allow to fix the threads per task to one value only, instead of a range.

Currently, Linux users can choose between exactly 1 thread/task, or randomly 1...2 threads/task, or randomly 1/2/4 threads per task, or randomly 1/2/4/8 threads per task. Frankly, the random options are completely bogus.

Whenever I run projects with multithreaded applications on my hosts, I always configure the client to run tasks with one uniform thread count per task. Not doing this will soon confuse the work queue management, and leave me with an under-utilized host, which I detest to no end.


2. Allow other thread counts than just 1, 2, 4, or 8.

I have yet to run proper tests, but it seems to me that while there is a throughput loss when going from 1 to >1 thread per task (as expected, due to inter-process synchronization overhead), there is very good scaling from a few to several more threads per task (as expected from such a long-running workload).

And what's more, it seems the thread count does not have to be a power of two. I started a 14-threaded tasks successfully, but it has yet to complete, and to validate of course.

Thread counts which are not a power of two will be good to have on 6-, 12, 14-, ... -core hosts.


3. Allow more than 8 threads per task.

I ran several 16-threaded tasks by now. The few which validated by now appear to have reasonable scaling compared with 4- and 8-threaded tasks.

I tried to start one 32-threaded task but it exited after a few seconds. I.e. there must have been an error which was not reported upwards to the boinc wrapper. I need to do some offline tests to check this out.


4. As a band-aid until some of the above can be implemented: Allow the anonymous platform.

I set up clients with an app_info.xml and the necessary project files in order to implement the above items locally. But when these clients requested work, the request failed with "HTTP internal server error".

For now, I am working around the lack of app_info.xml support by manual editing of the nwchem_t1_worker_0.19.sh file. The modification does not persist over a client restart though, of course.


PS,
while it is for certain that the single-threaded jobs will give best throughput, I am personally not keen on tasks which might require several days to complete.

xii5ku wrote:

it seems the thread count does not have to be a power of two. I started a 14-threaded tasks successfully, but it has yet to complete, and to validate of course.

This 14-threaded task validated by now. I shall try more of this, perhaps next week.

Why would you prefer a x-thread WU, over running x- amount of single threaded WUs?
In Linux it doesn't make sense, but I get what you're saying if you're running virualbox, and each WU loads in it's own virtual environment.

Sometimes it is convenient to be able to finish the work within less than half a day after download, rather than in two or three days.

1. Allow to fix the threads per task to one value only, instead of a range.

Currently, Linux users can choose between exactly 1 thread/task, or randomly 1...2 threads/task, or randomly 1/2/4 threads per task, or randomly 1/2/4/8 threads per task. Frankly, the random options are completely bogus.

Whenever I run projects with multithreaded applications on my hosts, I always configure the client to run tasks with one uniform thread count per task. Not doing this will soon confuse the work queue management, and leave me with an under-utilized host, which I detest to no end.

Are you saying this does not work???

<app_config>
<app>
    <name>nwchem_long</name>
    <!-- Xeon E5-2699 v4  22c44t  L3 Cache = 55 MB  -->
</app>
<app_version>
    <app_name>nwchem_long</app_name>
    <plan_class>t1</plan_class>
    <avg_ncpus>18</avg_ncpus>
    <cmdline>--nthreads 18</cmdline>
</app_version>
</app_config>

---

Nope, it does not work. I can't find the <plan_class> definition in the client_state file. It works fine for LHC ATLAS.

---