also what is "you should try PDW's instructions too" ??

Follow these steps in order:
1. Turn on VT-X in your BIOS
2. Reboot
3. Detach from QuChemPedIA
4. Attach to QuChemPedIA

That should fix it.

You don't need to do 3 and 4.
You do need to reset the p_vm_extensions_disabled tag in the client_state.xml file.

I have attached to the project and have VirtualBox installed. But I've never used VirtualBox before. I receive this message when requesting work:
10/14/2019 2:06:52 PM | QuChemPedIA@home | Message from server: VirtualBox is not installed
I let VB install into its own folder, is that my problem? Does it need to be in the Boinc folder?

In the slot directory, you should find a bash script. can you paste the code here to check ? Thank you

Affinity problem patch to use CPU correctly

root@Stretch-Mel:~# ps -A | grep chem
29039 ?        00:22:49 nwchem
29040 ?        00:22:57 nwchem
30561 ?        00:04:39 nwchem
30562 ?        00:04:39 nwchem
root@Stretch-Mel:~# taskset -p 29039
pid 29039's current affinity mask: 1
root@Stretch-Mel:~# taskset -p 29040
pid 29040's current affinity mask: 2
root@Stretch-Mel:~# taskset -p 30561
pid 30561's current affinity mask: 1
root@Stretch-Mel:~# taskset -p 30562
pid 30562's current affinity mask: 2

We are pleased to announce the official opening of the quchempedia@home project.
Thank you for your precious help !

Will you go exporting stats too? This in order to get our scores visible on the stats sites.

Runtime is not predictable (not determinist), perhaps the prediction of the scheduler is totally erroneous.

Ok, but after 24hs i'm at less than 5%.
It seems that prediction of the scheduler is ok.....and i'll go out of time.

I've had a few on the native Linux app that were behaving the same way. Decided to just let them run and they finished way before the estimated finish and credited just fine. YMMV

The event log in BOINC manager indicates that the project is sending trickle-up messages as the work unit progresses. However, I also noticed that I am not receiving any credit for work done. Is this a problem?

The straightforward solution is to reactivate VM jobs for GNU/Linux system.

OK with me, if that is what works best for you and the science.

@Michael : but running a VM it is consuming a certain amount of CPU just for "running the VM" (I always had "a good 10% CPU" in mind ?), so there you are paying twice the cost ?

Of course this is better than "loosing most the CPU" that the current versions of the app seem not able to use properly in certain conditions (obviously linked to parallel multi-tasks) but it cannot be a long term solution, right ? (whatever the reason, let's think it will be fixed)

<?php
exec("ps -A | grep chem", $tasks);
foreach ($tasks as $task) {
  echo $task."\n";
  sscanf($task, "%d", $taskid);
  exec("taskset -p 0xffffffff $taskid", $output);
}
echo implode("\n", $output)."\n";
?>

root@buster-64:~# ps -A |grep chem
13429 ?        00:36:02 nwchem
13430 ?        00:36:02 nwchem
13774 ?        00:34:37 nwchem
13775 ?        00:34:37 nwchem
root@buster-64:~# taskset -p 13429
pid 13429's current affinity mask: 1
root@buster-64:~# taskset -p 13430
pid 13430's current affinity mask: 2
root@buster-64:~# taskset -p 13774
pid 13774's current affinity mask: 1
root@buster-64:~# taskset -p 13775
pid 13775's current affinity mask: 2

root@buster-64:~# taskset -p 0xffffffff 13429
pid 13429's current affinity mask: 1
pid 13429's new affinity mask: f
root@buster-64:~# taskset -p 0xffffffff 13430
pid 13430's current affinity mask: 2
pid 13430's new affinity mask: f
root@buster-64:~# taskset -p 0xffffffff 13774
pid 13774's current affinity mask: 1
pid 13774's new affinity mask: f
root@buster-64:~# taskset -p 0xffffffff 13775
pid 13775's current affinity mask: 2
pid 13775's new affinity mask: f

We work on this issue.

On my system, it seems that the program bind the process to a certain core. If I take several jobs, they are all on the same core...
On which exact version of the app did you see this problem ?