Good news!
My first two, real multithreaded, 8 CPU QChem Long WUs arrived and are crunching with success!
Instead of 3 days for 1CPU, they seem to crunch at around 7.5 to 10 hours est...

The boinc site, "Max # of CPUs for this project" wasn't set, but has a maximum setting of #8 cores.
8 is a good setting, perhaps 12 would also be possible, and slightly better.
24 is too much, as it'll hog up an entire 3900x, and most of a 3950x.
The good thing about such WUs is on Ryzens, they should have shared L-3 cache, allowing data to be shared between cores...
Would be nice if Quchempedia could use that advantage, though current 3000 series chipsets have 2 CPU blocks of 6 or 8 cores.
4000 chipsets should be able to share that data between all cores.

Instead of 3 days for 1CPU, they seem to crunch at around 7.5 to 10 hours est.

That is just due to normal variations. I crunch with one core per work unit (t1) on a Ryzen 3600 (Ubuntu 18.04), and see 6 to 28 hours in the log at the moment.

First 4 core WUs also processing well!
My PPD count for the day went up by 2x (I do share projects)

I believe 4 core WUs are a big improvement, especially on AMD Ryzen 3000 series CPUs, over the single threaded WUs!
Shared l-cache might be helping out a lot!

Good job Quchempedia team!

I believe 4 core WUs are a big improvement, especially on AMD Ryzen 3000 series CPUs, over the single threaded WUs!
Shared l-cache might be helping out a lot!

OK, I will give it a try on my Ryzen 3600. Sometimes the PPD does not correspond to the work done though. It is a strange credit system, and I normally pay no attention to it.
But if it gets more work done, that is another matter.

"NWChem long" is not a multithreaded application in the stricter sense, in which one process maintains several threads which operate on shared data. Instead, the application spawns one or more separate processes, each operating on own data. These sub-processes are synchronizing with each other only occasionally, via message passing. Therefore I presume that processor cache does *not* make a difference for what little or large overhead there might be for running "NWChem long" with more than a single thread.

Architecturally, a single job of this application could even be spread over an Ethernet cluster of computers, or an Infiniband cluster. When the message passing has to go via a network like this, then there might be a bigger performance impact from communications latency though.

Thanks. I am back to a single core. I haven't figured out why the multi-core version is even offered, as I haven't seen an advantage.

EDIT: I see your other post. It makes sense if you need a shorter work unit.

I'm wondering if those multi thread WUs are the ones giving validation errors?
I've got 900 of those, where I presumably not get any points for.

I'm wondering if those multi thread WUs are the ones giving validation errors?
I've got 900 of those, where I presumably not get any points for.

I don't see that in your results. Your validation errors are all t1, aren't they?
(Strictly speaking, I guess they are all "multi-threaded", just with t=1).

But they are high on some of your machines, at over 5%. I normally get few invalids.
And I don't see much difference in the hardware to account for it. Maybe bad luck.
https://quchempedia.univ-angers.fr/athome/results.php?hostid=2356

You aren't overclocking, are you?

hi,, task are very long,, sometimes falling, error in validation, other probllems when computer is slowed with VM runs, and other probllems(low credit for one day task)
will back later when you develop non vm task and more stable.
thanks

I'm wondering if those multi thread WUs are the ones giving validation errors?

And another thing is that you are running either older (4.5) or newer (5.4) version of Linux than is standard in Ubuntu 18.04.4, which is 5.3.0-62 at the moment.
Maybe that leads to incompatibilities with certain libraries? I really don't know, but throw it out.