Are tasks being sent out for CUDA80 plan_class? I have only received new tasks on my 1080Ti with driver 418 and none on another system with 10/1070Ti with driver 396, which doesn't support CUDA100

Yes CUDA80 is supported, see apps page here:https://www.gpugrid.net/apps.php
Also see FAQ for ACEMD3 here: https://www.gpugrid.net/forum_thread.php?id=5002

there was a task which ended after 41 seconds with:
195 (0xc3) EXIT_CHILD_FAILED

stderr here: http://www.gpugrid.net/result.php?resultid=21514460

unfortunately ACEMD3 no longer tells you the real error. The wrapper provides a meaningless generic message. (error 195)
The task error in your STDerr Output is

# Engine failed: Particle coordinate is nan

I had this twice on one host. Not sure if I am completely correct as ACEMD3 is a new beast we have to learn and tame, but in my case I reduced the Overclocking and it seemed to fix the issue, though that could just be a coincidence.

I had a couple errors on my windows 7 computer, and none on my windows 10 computer, so far. In my case, it's not overclocking, since I don't overclock.

http://www.gpugrid.net/results.php?hostid=494023&offset=0&show_names=0&state=0&appid=32

Yes, I do believe we need some more testing.

Are tasks being sent out for CUDA80 plan_class? I have only received new tasks on my 1080Ti with driver 418 and none on another system with 10/1070Ti with driver 396, which doesn't support CUDA100

Yes CUDA80 is supported, see apps page here:https://www.gpugrid.net/apps.php
Also see FAQ for ACEMD3 here: https://www.gpugrid.net/forum_thread.php?id=5002

Then the app requires an odd situation in Linux where it supposedly supports CUDA 80 but to use it requires a newer driver beyond it.

What driver/card/OS combinations are supported?

Windows, CUDA80 Minimum Driver r367.48 or higher
Linux, CUDA92 Minimum Driver r396.26 or higher
Linux, CUDA100 Minimum Driver r410.48 or higher
Windows, CUDA101 Minimum Driver r418.39 or higher

There's not even a Linux CUDA92 plan_class so I'm not sure what thats for in the FAQ.

I just wanted to confirm, you need a driver supporting CUDA100 or CUDA101, then even a GTX670 can crunch the "acemd3" app.

See computer: http://www.gpugrid.net/show_host_detail.php?hostid=486229

Although it will not make the 24 hours deadline, and I can tell, the GPU is extremely stressed. I will run some more WUs on it, to confirm that it can handle the new app. And afterwards it will go to the summer pause or might be retired from BOINC altogether.

Are tasks being sent out for CUDA80 plan_class? I have only received new tasks on my 1080Ti with driver 418 and none on another system with 10/1070Ti with driver 396, which doesn't support CUDA100

Yes CUDA80 is supported, see apps page here:https://www.gpugrid.net/apps.php
Also see FAQ for ACEMD3 here: https://www.gpugrid.net/forum_thread.php?id=5002

Then the app requires an odd situation in Linux where it supposedly supports CUDA 80 but to use it requires a newer driver beyond it.

What driver/card/OS combinations are supported?

Windows, CUDA80 Minimum Driver r367.48 or higher
Linux, CUDA92 Minimum Driver r396.26 or higher
Linux, CUDA100 Minimum Driver r410.48 or higher
Windows, CUDA101 Minimum Driver r418.39 or higher

There's not even a Linux CUDA92 plan_class so I'm not sure what thats for in the FAQ.

And now I got the 1st CUDA80 task on that system w/o any driver changes.

there was a task which ended after 41 seconds with:
195 (0xc3) EXIT_CHILD_FAILED

stderr here: http://www.gpugrid.net/result.php?resultid=21514460

Checking this task, it has failed on 8 computers so it is just a faulty work unit.
clocking would not be the cause as previously stated.

there was a task which ended after 41 seconds with:
195 (0xc3) EXIT_CHILD_FAILED

stderr here: http://www.gpugrid.net/result.php?resultid=21514460

unfortunately ACEMD3 no longer tells you the real error. The wrapper provides a meaningless generic message. (error 195)
The task error in your STDerr Output is

# Engine failed: Particle coordinate is nan

I had this twice on one host. Not sure if I am completely correct as ACEMD3 is a new beast we have to learn and tame, but in my case I reduced the Overclocking and it seemed to fix the issue, though that could just be a coincidence.

I had a couple errors on my windows 7 computer, and none on my windows 10 computer, so far. In my case, it's not overclocking, since I don't overclock.

http://www.gpugrid.net/results.php?hostid=494023&offset=0&show_names=0&state=0&appid=32

Yes, I do believe we need some more testing

Agreed, testing will be an ongoing process...some errors cannot be fixed.

this task had an error code 194...

finish file present too long</message>

This error has been seen in ACEMD2 and listed as "Unknown"

Matt Harvey did a FAQ on error codes for ACEMD2 here
http://gpugrid.net/forum_thread.php?id=3468

Finally Cuda 10.1! Supprot for Turing Cuda Cores other words.
My RTX 2060 start crunching.
Will post later time.

this task had an error code 194...
finish file present too long</message>

This is a bug in the BOINC 7.14.2 client and earlier versions. You need to update to the 7.16 branch to fix it.
Identified/quantified in https://github.com/BOINC/boinc/issues/3017
And resolved for the client in:
https://github.com/BOINC/boinc/pull/3019
And in the server code in:
https://github.com/BOINC/boinc/pull/3300

this task had an error code 194...
finish file present too long</message>

This is a bug in the BOINC 7.14.2 client and earlier versions. You need to update to the 7.16 branch to fix it.
Identified/quantified in https://github.com/BOINC/boinc/issues/3017
And resolved for the client in:
https://github.com/BOINC/boinc/pull/3019
And in the server code in:
https://github.com/BOINC/boinc/pull/3300

Thanks for the info and links. Sometimes we overlook the Boinc Client performance.

From the Berkeley download page(https://boinc.berkeley.edu/download_all.php):

7.16.3 Development version
(MAY BE UNSTABLE - USE ONLY FOR TESTING)
and
7.14.2 Recommended version

This needs to be considered by volunteers, install latest version if you are feeling adventurous. (any issues you may find will help the Berkeley team develop the new client)

Alternatively,
- reducing the CPU load on your PC and/or
- ensuring the PC is not rebooted as the finish file is written,
may avert this error.

I haven't had a single instance of "finish file present" errors since moving to the 7.16 branch. I used to get a couple or more a day before on 7.14.2 or earlier.

It may be labelled an unstable development revision, but it is as close to general release stable as you can get. The only issue is that it is still in flux as more commits get added to it and the version number gets increased.

For me, 100% on GPU is not the best ;-)
Because I have just one card on the pc, and I can't see videos when GPUgrid is running. Even if I ask to smplayer or vlc to use the CPU So I have to pause this project when I use my pc.
Maybe one day we will can put some priority to the use of GPU (on linux).
I think I will buy a cheap card for manage the TV and play movies. But well, in general I am at work or somewhere else...

Nice to have some work. Folding@Home will wait. I was thinking to change, the others BOINC projects running on GPU doesn't interest me.

I see you have a RTX and a GTX.
You could save your GTX for video and general PC usage and put the RTX full time on GPU tasks.

I find this odd that you are having issues seeing videos. I noticed that with my system as well and it was not the GPU that was having trouble, it was the CPU that was overloaded. After I changed the CPU time to like 95% then I had no trouble watching videos.

After much tweaking on the way BOINC and all the projects I run use my system, I finally have it to where I can watch videos without any problems and I use a GTX 1050TI as my primary card along with a Ryzen 2700 with no video processor.

There must be something overloading your system if you can't watch videos on a RTX GPU while running GPU Grid.

I am getting high CPU/South bridge temps on one of my PCs with these latest work units.

The PC is http://www.gpugrid.net/show_host_detail.php?hostid=160668
and the current work unit is http://www.gpugrid.net/workunit.php?wuid=16866756

Every WU since November 22, 2019 had been exhibiting high temperatures on this PC. The previous apps never exhibited this. In addition, I found the PC unresponsive this afternoon. I was able to reboot, however, this does not give me a warm fuzzy feeling about continuing to run GPUGrid on this PC.

Anyone else seeing something similar or is there a solution for this?

Thanks.

---

I am getting high CPU/South bridge temps on one of my PCs with these latest work units.

That's because of two reasons:
1. The new app uses a whole CPU thread (or core, if there's no HT or SMT) to feed the GPU
2. The new app is not hindered by WDDM.

Every WU since November 22, 2019 had been exhibiting high temperatures on this PC. The previous apps never exhibited this.

That's because of two reasons:
1. The old app didn't feed the GPU with a full CPU thread unless the user configured it with the SWAN_SYNC environmental variable.
2. The performance of the old app was hindered by WDDM (under Windows Vista...10)

In addition, I found the PC unresponsive this afternoon. I was able to reboot, however, this does not give me a warm fuzzy feeling about continuing to run GPUGrid on this PC.

Anyone else seeing something similar or is there a solution for this?

There are a few options:
1. reduce the GPU's clock frequency (and the GPU voltage accordingly) or its power target.
2. increase cooling (cleaning fins, increasing air ventilation/fan speed).
If the card is overclocked (by you, or the factory) you should re-calibrate the overclock settings for the new app.
A small reduction in GPU voltage and frequency results in perceptible decrease of the power consumption (=heat output), as the power consumption is in direct ratio of the clock frequency multiplied by the GPU voltage squared.

I have found that running GPU's at 60-70% of their stock power level is the sweet spot in the compromise between PPD and power consumption/temps. I usually run all of my GPU's at 60% power level.

Finally Cuda 10.1! Supprot for Turing Cuda Cores other words.
My RTX 2060 start crunching.
Will post run-time later.

13134.75 seconds run-time @ RTX 2060, Ryzen 2600,Windows 10 1909.
Average GPU CUDA utilisation 99%.
No Issue at all with those workunit.

[quote]1. The old app didn't feed the GPU with a full CPU thread unless the user configured it with the SWAN_SYNC environmental variable.

Something was making my Climate models unstable and crashing them. That was the reason I lassoed in the GPU through SWAN_SYNC. Now my Climate models are stable. Plus I am getting better clock speeds.

I am getting high CPU/South bridge temps on one of my PCs with these latest work units.

As commented in several threads along GPUGrid forum, new ACEMD3 tasks are challenging our computers to their maximum.
They can be taken as a true hardware Quality Control!
Either CPUs, GPUs, PSUs and MoBos seem to be squeezed simultaneously while processing theese tasks.
I'm thinking of printing stickers for my computers: "I processed ACEMD3 and survived" ;-)

Regarding your processor:
Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz
It has a rated TDP of 130W. A lot of heat to dissipate...
It was launched on Q3/2013.
If it has been running for more than three years, I would recommend to renew CPU cooler's thermal paste.
A clean CPU cooler and a fresh thermal paste usually help to reduce CPU temperature by several degrees.

Regarding chipset temperature:
I can't remember any motherboard that I can touch chipset heatsinks with confidence.
Chipset heat evacuation is based in most of standard motherboards on passive air convection heatsinks.
If there is room at the upper back of your computer case, I would recommend to install an extra fan to extract heated air and improve air circulation.

Wow. My GTX 980 on Ubuntu 18.04.3 is running at 80C. It is a three-fan version, not overclocked, with a large heatsink. I don't recall seeing it above 65C before.

I can't tell about the CPU yet. It is a Ryzen 3700x, and apparently the Linux kernel does not support temperature measurements yet. But "Tdie" and "Tctl", whatever they are, report 76C on Psensor.

That is good. I want to use my hardware, and it is getting colder around here.

Tdie is the cpu temp of the 3700X. Tctl is the package power limit offset temp. The offset is 0 on Ryzen 3000. The offset is 20° C. on Ryzen 1000 and 10° C. on Ryzen 2000. The offset is used for cpu fan control.

Tdie and Tctl is provided by the k10temp driver. You still have access to the sensors command if you install lm-sensors.

Ryzen only provides a monolithic single core temp for all cores. It doesn't support individual core temps like Intel cpus.

If you have a ASUS motherboard with a WMI BIOS, there is a driver that can report all the sensors on the motherboard, the same as you would get in Windows.