I have a 2600K processor with 6 logical cores available for the QC app.

This app_config.xml starts 3 concurrent QC apps with 2 cores each. We'll see how it goes.

It seems one task of 3 is progressing much more slowly than the other 2 so I'll reduce max concurrent tasks to 2 in the app_config.

Is there a limit to using 4 logical cores per processor?

Toni, there has been an other reason, I abstained from the QMML app on the AMD1700x computer apart from failing WUs and freezing the computer:

QMML app clogs the scheduler of BOINC and therefor blocks the other projects to download additional WUs automaticly when requiered (I do run only one instance of QMML app on this computer). So the computer ends-up to run only one instance of QMML app and a GPU app. When I ask manually for additional WUs on the other projects, then they get downloaded. So it is to run only GPUGRID on this computer or run GPUGRID only on the GPU.

* CPU threads are limited to 4 (you should still be able to crunch multiple WUs at once, please check)

I haven't had any issue with the QC tasks running alongside my usual SETI tasks. I reduce the number of Seti cpu tasks when I run the QC task set to use 4 cores. The Seti and Einstein projects download and run tasks normally without any manual intervention.

I did have to increase my disk space for the QC task I ran this morning when GPUGrid complained it needed an additional 600 MB of space. I have a larger than normal amount of Seti work on board today to make through the scheduled outage.

Maybe the disk space needs to be increase or the resource share changed.

I have a AMD 1800X in my Ryzen cruncher.

Thanks Keith for your comments.

I do not run SETI on the CPU, I run PRIMEGRID and SETI on the GPU only.

I do run ODLK1 on the CPU, as this is the only project that does not freeze frequently my computer/CPU (once a day).

The ODLK1 tasks however do not download when I am crunching the QMML app.

The freezing might as well be that I am mildly overclocked the CPU (3770 MHz) and run the RAM at 2966 MHz (RAM is rated at 3000 MHz), but I have not had the time to investigate further.

I've gotten pretty good at tuning Ryzen for 24/7 distributed computing. I have had the 1700X since launch in March of last year.

I run the 1700X at 3.9Ghz and the memory at 3333Mhz CL14 with fast timings.

The 1800X being newer and better made runs at 3.95 Ghz and 3333Mhz CL14 fast timings.

Do you get BSOD's or black screens? BSOD's are almost invariably due to aggressive memory clocks, memory instability or IMC weakness.

Black screens, (computer appears frozen, no display or keyboard or mouse input recognized) with no error logs generated are caused by cpu lockup because of insufficient VDDCR cpu voltage for the desired cpu clocks.

Both my Ryzens run for weeks without errors. Only reason uptime is not longer is because of OS updates or whatever.

Black screens, (computer appears frozen, no display or keyboard or mouse input recognized) “with no error logs generated” are caused by cpu lockup because of insufficient VDDCR cpu voltage for the desired cpu clocks.

We probably should converse via PM so as to not pollute or hijack the thread.

Wow, how did you manage to get 1200-1300 credits for your QC tasks today. What's your secret?

So far with testing, I have only been able to run QMML work units on systems with up to 4 cores.

On any of my systems with 8 or 16 cores, attempting to run multiple QMMLs, they all end prematurely with a computational error.

So far with testing, I have only been able to run QMML work units on systems with up to 4 cores.

On any of my systems with 8 or 16 cores, attempting to run multiple QMMLs, they all end prematurely with a computational error.

@Keith: Thanks for you PM.
@Keith: I did nothing! Toni changed the credits and my two computers have higher credits.

@NUCCpod_NAPTIMELABS_01 and mmonnin: It is correct you have to limit QMML app to only one concurrent task at a time. Then it works on my AMDs. There is circulating an app_config in the forums that works.

@klepel: Well Toni didn't change the credits for me it appears.

I just downloaded a couple more QC tasks hoping that the one I did yesterday was a fluke or carryover from the "old" tasks with the tiny credit.

Nope. Still getting very little credit for these QC tasks and not worth tying up 4 cores.

Haven't a clue why I get such little credit and others are getting 24 times more for the same cpu elapsed times.

Run time 1,854.06
CPU time 7,224.95
Validate state Valid
Credit 47.13

Haven't a clue why I get such little credit and others are getting 24 times more for the same cpu elapsed times.

Just give me one QC task that gets as much credit as yours or klebel's and I would have hope. Alas the 110 credits I got yesterday for this Task 16998146 is the most I've ever seen. My credits have ranged from 6-47 over 35 tasks so far with the one above the only outlier.

OK, so I once again crunched some more QC task. This time I reduced the core count to two to see if it made any difference. Nope. Still extremely low credit compared to everyone else that has posted in these threads.

Run time 4,362.76
CPU time 8,635.24
Validate state Valid
Credit 91.52

Run time 4,270.13
CPU time 8,440.52
Validate state Valid
Credit 90.31

Task 17003892
Task 17003905

The problem with multiple WUs starting at the same time, should be fixed (or otherwise a lot of calculation errors will be produced).

Or just set max_concurrent to 1 and avoid the issue entirely until the applications and software for the problem gets resolved.

Or just set max_concurrent to 1 and avoid the issue entirely until the applications and software for the problem gets resolved.

Every donor is different. I don't have GPUGrid as my sole project so the crunchers never go idle, there is always work being done for someone.

As with most projects, there is always a shortage of manpower, money or time for keeping applications current and working.

I'll be watching for updates, but for now I'm also turning off CPU tasks.

Scheduler is telling batches to activate all at once. Rows of errors. I acknowledge that user fixes have been recommended but I don't want to program a solution that's beyond my capacity to correct once circumstances change.

Hope to be back soon!

I set up the quantum chem app on a second computer. I started with the following app_config.xml file:

But there is still the issue that whenever your QC tasks finish and more than 2 tasks are downloaded, that your system can try to start both tasks at the same time and then both will fail. There is no guaranteed method to stagger starting of multiple QC tasks in an unattended system on auto.

The only way to get around this situation is to do exactly what you posted. But requires your intervention at each new task startup.

Or just set max_concurrent to 1 and be done with it.

I am not seeing this situation at all.
My AMD Linux Fedora systems download more than one at a time but only ever try to run one at a time.
Even on my 8 core (+ 8 HT) only one starts and other projects keep running.

I am also running other applications but on a 4 core computer when GPU Grid starts it is the only thing that runs and only one at a time.

Not trying to control how things are run.

So I don't know what could be causing problems on your computers.

BOINC versions are 7.4.25 and 7.6.22

Conan

Quick update: I checked my logs and this thread again to see if I could resume tasks. To my surprise, tasks were resumed while I had still opted out.

ACEMD short runs (2-3 hours on fastest card): yes
ACEMD long runs (8-12 hours on fastest GPU): yes
ACEMD Beta: yes
Quantum Chemistry (Linux, CPU): no
Python Runtime : yes

I don't know what's broken but it's not cool.

I am not seeing this situation at all.
My AMD Linux Fedora systems download more than one at a time but only ever try to run one at a time.
Even on my 8 core (+ 8 HT) only one starts and other projects keep running.

I am also running other applications but on a 4 core computer when GPU Grid starts it is the only thing that runs and only one at a time.

Not trying to control how things are run.

So I don't know what could be causing problems on your computers.

BOINC versions are 7.4.25 and 7.6.22

Conan

Dayle Diamond said:

Quick update: I checked my logs and this thread again to see if I could resume tasks. To my surprise, tasks were resumed while I had still opted out.

If one has more than 4 cores and running max concurrent = 1, there is still the chance that boinc manager will flood your queue with all QC tasks and nothing from the other project. Esp when just starting up that setup before BM gets a better handle of the resource share it is a long term resource share.

I've personally had this happen using max concurrent on another project. 4 threads working, 28 idle. It's far from a perfect solution.

Dayle, do you perchance have the preference box checked for
If no work for selected applications is available, accept work from other applications?

I set up the quantum chem app on a second computer. I started with the following app_config.xml file:

<app_config>
<app>
<name>QC</name>
<max_concurrent>1</max_concurrent>
</app>
<app_version>
<app_name>QC</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>4</avg_ncpus>
<cmdline>--nthreads 4</cmdline>
</app_version>
</app_config>

Once the Work Units downloaded and 1 WU started w/4 threads, I edited the app_config.xml to change <max_concurrent>1</max_concurrent> to <max_concurrent>2</max_concurrent>. Then I restarted the boinc client and now I have 2 work units running simultaneously with 4 threads each. So far so good.

So, forgive me if this has been answered.

Is this planned to be fixed at some point?

No it hasn't been answered. Or even addressed by the developer as far as I can tell. Seems the resources lately have been in deploying and debugging the WSL QC app.