Hi,
my first new WU stop at 1% after 20 minutes of running.
I suspended and restart it, the elapsed time restart from 0.
After another 20 minutes of running, without increase of working progress i kill it.
For investigation see http://www.gpugrid.net/result.php?resultid=21501927
Thanks in advance.
K.
____________
Dreams do not always come true. But not because they are too big or impossible. Why did we stop believing.
(Martin Luther King)

Thank you Toni!

I already have my GTX 1070/1080 GPU's pegged to nearly 100% even with one WU running on each.

The GPU load does drop lower intermittently and also will drop PerfCap to Idle.

The new thing I am noticing is I am now hitting the Power PerfCap throttling the GPU's.

Hi,
my first new WU stop at 1% after 20 minutes of running.
I suspended and restart it, the elapsed time restart from 0.
After another 20 minutes of running, without increase of working progress i kill it.
For investigation see http://www.gpugrid.net/result.php?resultid=21501927
Thanks in advance.
K.

Sorry for mistake of configuration

Intel Quadcore Q9450 with 4GB (2*2 DDR3 at 1333) and GTX 750 TI

... here the log.

Output su Stderr
<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
aborted by user</message>
<stderr_txt>
19:10:11 (2408): wrapper (7.9.26016): starting
19:10:11 (2408): wrapper: running acemd3.exe (--boinc input --device 0)
Detected memory leaks!
Dumping objects ->
..\api\boinc_api.cpp(309) : {1583} normal block at 0x0000020099013380, 8 bytes long.
Data: < > 00 00 F9 98 00 02 00 00
..\lib\diagnostics_win.cpp(417) : {198} normal block at 0x0000020099011BA0, 1080 bytes long.
Data: <( ` > 28 11 00 00 CD CD CD CD 60 01 00 00 00 00 00 00
Object dump complete.

</stderr_txt>
____________
Dreams do not always come true. But not because they are too big or impossible. Why did we stop believing.
(Martin Luther King)

Sorry for mistake of configuration ... here the log.

Output su Stderr
<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
aborted by user</message>
<stderr_txt>
19:10:11 (2408): wrapper (7.9.26016): starting
19:10:11 (2408): wrapper: running acemd3.exe (--boinc input --device 0)
Detected memory leaks!
Dumping objects ->
..\api\boinc_api.cpp(309) : {1583} normal block at 0x0000020099013380, 8 bytes long.
Data: < > 00 00 F9 98 00 02 00 00
..\lib\diagnostics_win.cpp(417) : {198} normal block at 0x0000020099011BA0, 1080 bytes long.
Data: <( ` > 28 11 00 00 CD CD CD CD 60 01 00 00 00 00 00 00
Object dump complete.

</stderr_txt>
]]>

I'm not sure a GTX 750 series can run the new app. Let's see if one of the resident experts will know the answer.

I'm not sure a GTX 750 series can run the new app

Was this coincidence, or is the new version not being sent to GTX750ti cards?

Just starting a task on my GTX 1050TI (fully updated drivers, no overdrive, default settings)
Been running 30 mins and it did 2% finally.
You should change something in the code so it spits out decimal update % done information. I use that to check if the task is moving in Boinc Tasks.
Your config only updates the 1-x% and no decimal.
Memory usage is minimal compared to LHC ATLAS. You use only 331 MB real memory and 648 Virtual, which is more in the range of what Rosetta uses.
So it looks like I should have this task done in about 26 hrs from now.
For a GPU task it is taking a lot of CPU, it needs 100%+ all the time in CPU usage.

Hi, I'm running test 309 on an i7-860 with one GTX 750Ti and ACEMD 3 test is reporting 4.680%/Hr.
Better than my GTX 1060 and i7-7700K running test 725 @ 4.320%/Hr.
Why does the GTX 1060 run slower, Toni, anybody?
(running latest drivers)
____________
"Together we crunch
To check out a hunch
And wish all our credit
Could just buy us lunch"

Piasa Tribe - Illini Nation

I got this one today http://www.gpugrid.net/workunit.php?wuid=16850979 and it ran fine. As I've said before, Linux machines are quite ready.

Three finished so far, working on a fourth. Keep 'em coming.

Got one task. GTX1060 with Max-Q. Windows 10. Task errored out. Following is the complete story.
<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
23:16:17 (1648): wrapper (7.9.26016): starting
23:16:17 (1648): wrapper: running acemd3.exe (--boinc input --device 0)
# Engine failed: Error invoking kernel: CUDA_ERROR_ILLEGAL_ADDRESS (700)
02:43:35 (1648): acemd3.exe exited; CPU time 12377.906250
02:43:35 (1648): app exit status: 0x1
02:43:35 (1648): called boinc_finish(195)
0 bytes in 0 Free Blocks.
506 bytes in 8 Normal Blocks.
1144 bytes in 1 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 0 bytes.
Total allocations: 184328910 bytes.
Dumping objects ->
{1806} normal block at 0x000001C10FAA6190, 48 bytes long.
Data: <ACEMD_PLUGIN_DIR> 41 43 45 4D 44 5F 50 4C 55 47 49 4E 5F 44 49 52
{1795} normal block at 0x000001C10FAA6350, 48 bytes long.
Data: <HOME=D:\ProgramD> 48 4F 4D 45 3D 44 3A 5C 50 72 6F 67 72 61 6D 44
{1784} normal block at 0x000001C10FAA6580, 48 bytes long.
Data: <TMP=D:\ProgramDa> 54 4D 50 3D 44 3A 5C 50 72 6F 67 72 61 6D 44 61
{1773} normal block at 0x000001C10FAA6120, 48 bytes long.
Data: <TEMP=D:\ProgramD> 54 45 4D 50 3D 44 3A 5C 50 72 6F 67 72 61 6D 44
{1762} normal block at 0x000001C10FAA5CC0, 48 bytes long.
Data: <TMPDIR=D:\Progra> 54 4D 50 44 49 52 3D 44 3A 5C 50 72 6F 67 72 61
{1751} normal block at 0x000001C10FA8A0B0, 141 bytes long.
Data: <<project_prefere> 3C 70 72 6F 6A 65 63 74 5F 70 72 65 66 65 72 65
..\api\boinc_api.cpp(309) : {1748} normal block at 0x000001C10FAA86C0, 8 bytes long.
Data: < > 00 00 A4 0F C1 01 00 00
{977} normal block at 0x000001C10FA8D840, 141 bytes long.
Data: <<project_prefere> 3C 70 72 6F 6A 65 63 74 5F 70 72 65 66 65 72 65
{203} normal block at 0x000001C10FAA8CB0, 8 bytes long.
Data: < > 10 BB AA 0F C1 01 00 00
{197} normal block at 0x000001C10FAA5B70, 48 bytes long.
Data: <--boinc input --> 2D 2D 62 6F 69 6E 63 20 69 6E 70 75 74 20 2D 2D
{196} normal block at 0x000001C10FAA8030, 16 bytes long.
Data: < > 18 BA AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{195} normal block at 0x000001C10FAA83F0, 16 bytes long.
Data: < > F0 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{194} normal block at 0x000001C10FAA89E0, 16 bytes long.
Data: < > C8 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{193} normal block at 0x000001C10FAA7FE0, 16 bytes long.
Data: < > A0 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{192} normal block at 0x000001C10FAA8DA0, 16 bytes long.
Data: <x > 78 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{191} normal block at 0x000001C10FAA8B20, 16 bytes long.
Data: <P > 50 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{190} normal block at 0x000001C10FAA5A90, 48 bytes long.
Data: <ComSpec=C:\Windo> 43 6F 6D 53 70 65 63 3D 43 3A 5C 57 69 6E 64 6F
{189} normal block at 0x000001C10FAA7F90, 16 bytes long.
Data: < > D0 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{188} normal block at 0x000001C10FA9D540, 32 bytes long.
Data: <SystemRoot=C:\Wi> 53 79 73 74 65 6D 52 6F 6F 74 3D 43 3A 5C 57 69
{187} normal block at 0x000001C10FAA88F0, 16 bytes long.
Data: < > A8 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{185} normal block at 0x000001C10FAA8C10, 16 bytes long.
Data: < > 80 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{184} normal block at 0x000001C10FAA81C0, 16 bytes long.
Data: <X > 58 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{183} normal block at 0x000001C10FAA8210, 16 bytes long.
Data: <0 > 30 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{182} normal block at 0x000001C10FAA85D0, 16 bytes long.
Data: < > 08 FE A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{181} normal block at 0x000001C10FAA88A0, 16 bytes long.
Data: < > E0 FD A8 0F C1 01 00 00 00 00 00 00 00 00 00 00
{180} normal block at 0x000001C10FA8FDE0, 280 bytes long.
Data: < \ > A0 88 AA 0F C1 01 00 00 C0 5C AA 0F C1 01 00 00
{179} normal block at 0x000001C10FAA8800, 16 bytes long.
Data: <0 > 30 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{178} normal block at 0x000001C10FAA8A80, 16 bytes long.
Data: < > 08 B9 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{177} normal block at 0x000001C10FAA8850, 16 bytes long.
Data: < > E0 B8 AA 0F C1 01 00 00 00 00 00 00 00 00 00 00
{176} normal block at 0x000001C10FAAB8E0, 496 bytes long.
Data: <P acemd3.e> 50 88 AA 0F C1 01 00 00 61 63 65 6D 64 33 2E 65
{65} normal block at 0x000001C10FAA8C60, 16 bytes long.
Data: < > 80 EA D6 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{64} normal block at 0x000001C10FA9BA00, 16 bytes long.
Data: <@ > 40 E9 D6 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{63} normal block at 0x000001C10FA9B9B0, 16 bytes long.
Data: < W > F8 57 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{62} normal block at 0x000001C10FA9B960, 16 bytes long.
Data: < W > D8 57 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{61} normal block at 0x000001C10FA9B910, 16 bytes long.
Data: <P > 50 04 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{60} normal block at 0x000001C10FA9B870, 16 bytes long.
Data: <0 > 30 04 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{59} normal block at 0x000001C10FA9B780, 16 bytes long.
Data: < > E0 02 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{58} normal block at 0x000001C10FA9B730, 16 bytes long.
Data: < > 10 04 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{57} normal block at 0x000001C10FA9B690, 16 bytes long.
Data: <p > 70 04 D3 DA F7 7F 00 00 00 00 00 00 00 00 00 00
{56} normal block at 0x000001C10FA9B640, 16 bytes long.
Data: < > 18 C0 D1 DA F7 7F 00 00 00 00 00 00 00 00 00 00
Object dump complete.

</stderr_txt>

Enjoy reading it.

I'm not sure a GTX 750 series can run the new app.

Was this coincidence, or is the new version not being sent to GTX750ti cards?

Please, try updating drivers

would be useful if we were told which is the minimum required version number of the driver.

would be useful if we were told which is the minimum required version number of the driver.

This info can be found here:
http://gpugrid.net/forum_thread.php?id=5002

Hi, I'm running test 309 on an i7-860 with one GTX 750Ti and ACEMD 3 test is reporting 4.680%/Hr.
Better than my GTX 1060 and i7-7700K running test 725 @ 4.320%/Hr.
Why does the GTX 1060 run slower, Toni, anybody?
(running latest drivers)

would be useful if we were told which is the minimum required version number of the driver.

This info can be found here:
http://gpugrid.net/forum_thread.php?id=5002

oh, thanks very much; so all is clear now - I need to update my drivers on the two GTX750ti hosts.

Driver updates complete, and 1 of my 2 GTX750ti has already received a task, it's running well.

What I noticed, also on the other hosts (GTX980ti and GTX970), is that the GPU usage (as shown in the NVIDIA Inspector and GPU-Z) now is up to 99% most of the time; this was not the case before, most probably due to the WDDM "brake" in Win7 and Win10 (it was at 99% in WinXP which had no WDDM).
And this is noticable, as the new software seems to have overcome this problem.

http://www.gpugrid.net/result.php?resultid=21502590

Crashed and burned after going 2% or more.
Memory leaks

Updated my drivers and have another task in queue.

Toni (and GPUgrid team) set out with a vision to make the app more portable and faster. They have delivered. Thank you Toni (and GPUgrid team).

http://www.gpugrid.net/result.php?resultid=21502590

Crashed and burned after going 2% or more.
Memory leaks

Updated my drivers and have another task in queue.

Toni, since the new app is an obvious success - now the inevitable question: when will you send out the next batch of tasks?

Hi Toni

"Memory leaks": ignore the message, it's always there. The actual error, if present, is at the top.

WAITING FOR WU's

oh interesting.
then I guess I have to write a script to keep all your tasks on the 1050.
That's my better GPU anyway.

Why is CPU usage so high?
I expect GPU to be high, but CPU?
One thread running between 85-100+% on CPU

c'est déja fini le test aucune erreur sur mes 1050ti et sur ma 1080ti

http://www.gpugrid.net/result.php?resultid=21502590

Crashed and burned after going 2% or more.
Memory leaks

Updated my drivers and have another task in queue.

The memory leaks do appear on startup, probably not critical errors.

The issue in your case is ACEMD3 tasks cannot start on one GPU and be resumed on another.

From your STDerr Output:
.....
04:26:56 (8564): wrapper: running acemd3.exe (--boinc input --device 0)
.....
06:08:12 (16628): wrapper: running acemd3.exe (--boinc input --device 1)
ERROR: src\mdsim\context.cpp line 322: Cannot use a restart file on a different device!

It was started on Device 0
but failed when it was resumed on Device 1

Refer this FAQ post by Toni for further clarification:
http://www.gpugrid.net/forum_thread.php?id=5002

Why is CPU usage so high?
I expect GPU to be high, but CPU?
One thread running between 85-100+% on CPU

Thanks to all! To summarize some responses of the feedback above:

* GPU occupation is high (100% on my Linux machine)
* %/day is not an indication of performance because WU size differs between WU types
* Minimum required drivers, failures on notebook cards: see FAQ - thanks for those posting the links
* Tasks apparently stuck: may be an impression due to the % being rounded (e.g. 8h task divided in 100% fractions = no apparent progress for minutes)
* "Memory leaks": ignore the message, it's always there. The actual error, if present, is at the top.

I'm looking for a confirmation that the app works on windows machine with > 1 device. I'm seeing some

7:33:28 (10748): wrapper: running acemd3.exe (--boinc input --device 2)
# Engine failed: Illegal value for DeviceIndex: 2

http://www.gpugrid.net/result.php?resultid=21502590

Crashed and burned after going 2% or more.
Memory leaks

Updated my drivers and have another task in queue.

The memory leaks do appear on startup, probably not critical errors.

The issue in your case is ACEMD3 tasks cannot start on one GPU and be resumed on another.

From your STDerr Output:
.....
04:26:56 (8564): wrapper: running acemd3.exe (--boinc input --device 0)
.....
06:08:12 (16628): wrapper: running acemd3.exe (--boinc input --device 1)
ERROR: src\mdsim\context.cpp line 322: Cannot use a restart file on a different device!

It was started on Device 0
but failed when it was resumed on Device 1

Refer this FAQ post by Toni for further clarification:
http://www.gpugrid.net/forum_thread.php?id=5002

Solve the issue of stopping processing one type of card and attempting to finish on another type of card by changing your compute preferences of "switch between tasks every xx minutes" to a larger value than the default 60. Change to a value that will allow the task to finish on your slowest card. I suggest 360-640 minutes depending on your hardware.

The %Progress keeps resetting to zero on 2080 Ti's but seems normal on 1080 Ti's.
____________

I'm looking for a confirmation that the app works on windows machine with > 1 device. I'm seeing some

7:33:28 (10748): wrapper: running acemd3.exe (--boinc input --device 2)
# Engine failed: Illegal value for DeviceIndex: 2

Task completed and validated.

The %Progress keeps resetting to zero on 2080 Ti's but seems normal on 1080 Ti's.

The %Progress keeps resetting to zero on 2080 Ti's but seems normal on 1080 Ti's.

My impression so far is that Win7-64 can run four WUs on two 1080 Ti's fine on the same computer fine.
The problem seems to be with 2080 Ti's running on Win7-64. I'm running four WUs on one 2080 Ti with four Einstein or four Milkyway on the second 2080 Ti seems ok so far. Earlier when I had two WUs on each 2080 Ti along with either two Einstein or two Milkyway that it kept resetting.
All Linux computers with 1080 Ti's seem normal.
Plan to move my two 2080 Ti's back to a Linux computer and try that.

@rod4x4 which error? no resume on different cards is known, please see the faq.

Okay, my 1060 with Max-Q design completed one task and validated.

Okay, my 1060 with Max-Q design completed one task and validated.

My windows 10 computer on the RTX 2080 ti is finishing these WUs in about 6100 seconds, which is about the same time as computers running linux with same card.

Is the WDDM lag gone or is it my imagination?


The 18000 to 19000 seconds range are the these WUs running on the GTX 980 ti.



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

@Rod 4*4. I did make a change but I do not know it's relevance. I set SWAN_SYNC to 0. I did that for some other reason. Anyway, second WU completed and validated.

Is the WDDM lag gone or is it my imagination?

WU now require 1 CPU core - WU run slower on 4/5 GPUs with (4) CPU cores.

3 GPUs full speed while 4 or 5 cause GPU usage to tank.

ELISA WU GPU max power draw (55C GPU temp)

330W on 2080ti 95% GPU utilization (PCIe 3.0 x4) @ 1995MHz

115W on 1660 99% "" (PCIe 3.0 x4) @ 1995MHz

215W on 2080 89% "" (PCIe 2.0 x1) @ 1995MHz

Progress bar runtime (2080ti 1hr 40min) / (2080 2hr 40min) / (1660 5hr)

1660 runtime equal to the 980ti.

My windows 10 computer on the RTX 2080 ti is finishing these WUs in about 6100 seconds, which is about the same time as computers running linux with same card.

Is the WDDM lag gone or is it my imagination?

Is the WDDM lag gone or is it my imagination?

Given that the various tool now show a GPU utilization of mostly up to 99% or even 100% (as it was with WinXP before), it would seem to me that the WDDM does not play a role any more.

Hi,
many thanks for add new tasks, but please add again more tasks lol
bests regards
laurent from Belgium

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.

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

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

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

# Engine failed: Particle coordinate is nan

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.

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

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.

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

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.

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

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

finish file present too long</message>

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 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

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 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.

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?

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.

[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.

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

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.

Thanks. It is an ASRock board, and it probably has the same capability. I will look around.

AFAIK, only ASUS implemented an WMI BIOS to overcome the limitations and restrictions of using a crappy SIO chip on most of their boards.

The latest X570 boards went with a tried and true NCT6775 SIO chip that is well supported in both Windows and Linux.

To give you an idea of what the independent developer driver accomplished with his asus-wmi-sensor driver, this is the output of sensors command on my Crosshair VII Hero motherboard.

So you can at least look at the driver project at github, this is the link.
https://github.com/electrified/asus-wmi-sensors

OK, I will look at it occasionally. I think Psensor is probably good enough. Fortunately, the case has room for two (or even three) 120 mm fans side by side, so I can cool the length of the card better, I just don't normally have to.

It is now running Einstein FGRBP1, and is down to 69C. It will probably go down a little more.

EDIT: I also have a Ryzen 3600 machine with the same motherboard (ASRock B450M PRO4) and BIOS. Tdie and Tctl are reporting 95C. I will shut it down and put on a better cooler; I just used the stock one that came with the CPU.

I am running at GTX 1050 at full load and full OC and it goes to only 56C. Fan speed is about 90% of capacity.

For heat, my system with a Ryzen7 2700 running at 40.75 GHZ in OC and running a wide range of projects ranging from LHC (including ATLAS) to easier stuff like Rosetta plus this new stuff, rarely gets above 81C.

I upgraded my case recently and have a Corsair case with 2x 240 fans on the front intake, 1 x 120 exhaust fan on the rear and 1 x 120 intake fan on the bottom. Cooling is with a Artic Cooling Freezer using stock fans which are as good or better than Noctura fans. My top grill can do a 360mm radiator but I opted for a 240 due to budget. So I have one extra slot for hot air to escape.

I burned a Corsair single radiator with push/pull fans after 3 years. And a gamer I met at a electronics box store in the US while I was home visiting family told me she uses the Arctic radiator and has no problems. It is also refillable.

This kind of cooling is what I consider the best short of a gas cooled system or one of those 1,000 dollar external systems.

@ Keith Myers
This would be steam!

my system with a Ryzen7 2700 running at 40.75 GHZ ... rarely gets above 81C.

No..its just 177F. No idea where you got that value from.
Water boils at 212F and that would trigger a thermal shutdown on the CPU.

AMD specifies 85°C as the maximum safe temperature for a Ryzen™ 7 2700X processor. That's the chip with the video co-processor, I am just pure CPU.
From what I can see, thermal shut down is 100-115C according to some posts.

If the chip is 80C, then I guess the outgoing water would be that, but the radiator does not feel that hot. According to NZXT CAM monitoring I am only using 75% of the temperature range.

Checked AMD website. Max Temp for my CPU is 95C or 203F. So I am well within the limits of the design specs of this CPU. Your temperature calculation was way off.

@ Keith Myers
This would be steam!

Water In: +216.0°C

@ Greg _BE

my system with a Ryzen7 2700 running at 40.75 GHZ ... rarely gets above 81C.

Wow!!



@ Jim1348
This is the output from standard sensors package.

>sensors nct6779-isa-0290 nct6779-isa-0290 Adapter: ISA adapter Vcore: +0.57 V (min = +0.00 V, max = +1.74 V) in1: +1.09 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: +3.23 V (min = +2.98 V, max = +3.63 V) +3.3V: +3.23 V (min = +2.98 V, max = +3.63 V) in4: +1.79 V (min = +0.00 V, max = +0.00 V) ALARM in5: +0.92 V (min = +0.00 V, max = +0.00 V) ALARM in6: +1.35 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB: +3.46 V (min = +2.98 V, max = +3.63 V) Vbat: +3.28 V (min = +2.70 V, max = +3.63 V) in9: +0.00 V (min = +0.00 V, max = +0.00 V) in10: +0.75 V (min = +0.00 V, max = +0.00 V) ALARM in11: +0.78 V (min = +0.00 V, max = +0.00 V) ALARM in12: +1.66 V (min = +0.00 V, max = +0.00 V) ALARM in13: +0.91 V (min = +0.00 V, max = +0.00 V) ALARM in14: +0.74 V (min = +0.00 V, max = +0.00 V) ALARM fan1: 3479 RPM (min = 0 RPM) fan2: 0 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +40.0°C (high = +0.0°C, hyst = +0.0°C) sensor = thermistor CPUTIN: +48.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +8.0°C sensor = thermistor AUXTIN1: +40.0°C sensor = thermistor AUXTIN2: +38.0°C sensor = thermistor AUXTIN3: +40.0°C sensor = thermistor SMBUSMASTER 0: +57.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled

The real Tdie is shown as "SMBUSMASTER 0" already reduced by 27° (Threadripper offset) using the following formula in /etc/sensors.d/x399.conf

chip "nct6779-isa-0290" compute temp7 @-27, @+27

@ Keith Myers
This would be steam!
Water In: +216.0°C

The heatsink on the Ryzen 3600 that reports Tdie and Tctl at 95C is only moderately warm to the touch. That was the case when I installed it.

So there are two possibilities: the heatsink is not making good contact to the chip, or else the reading is wrong. I will find out soon.

EDIT: The paste is spread out properly and sticking fine. It must be that the Ryzen 3600 reports the temps differently, or else is interpreted wrong. That is my latest build by the way, put together within the last month.

https://i.pinimg.com/originals/94/63/2d/94632de14e0b1612e4c70111396dc03f.jpg

c to f degrees chart

I have checked my system with HW Monitor,CAM,MSI Command Center and Ryzen Master. All report the same thing. 80C and AMD says max 95C before shutdown.

I'll leave it at that.

No idea where you got that value from.

Water In: +216.0°C
Water Out: +35.0°C

If the chip is 80C, then I guess the outgoing water would be that, but the radiator does not feel that hot.

This would be steam!

Water In: +216.0°C

@ Keith Myers
This would be steam!
Water In: +216.0°C

I saw the same thing. Funny Huh!

I just made an interesting observation comparing my computers with GTX1650 and GTX1660ti with ServicEnginIC´s computers:
http://www.gpugrid.net/show_host_detail.php?hostid=147723
http://www.gpugrid.net/show_host_detail.php?hostid=482132
mine:
http://www.gpugrid.net/show_host_detail.php?hostid=512242
http://www.gpugrid.net/show_host_detail.php?hostid=512293
The computers of ServicEnginIC are approx. 10% slower than mine. His CPUs are Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz and Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, mine are two AMD Ryzen 5 2600 Six-Core Processors.
Might it be that the Wrapper is slower on slower CPUs and therefore slows down the GPUs? Is this the experience from other users as well?

The heatsink on the Ryzen 3600 that reports Tdie and Tctl at 95C is only moderately warm to the touch. That was the case when I installed it.

So there are two possibilities: the heatsink is not making good contact to the chip, or else the reading is wrong. I will find out soon.

EDIT: The paste is spread out properly and sticking fine. It must be that the Ryzen 3600 reports the temps differently, or else is interpreted wrong. That is my latest build by the way, put together within the last month.

Might it be that the Wrapper is slower on slower CPUs and therefore slows down the GPUs?
Is this the experience from other users as well?

Thank you Rod4x4, I later saw the first WU speed up and subsequent units have been running over 12%/Hr without issues. Guess I jumped on that too fast. The 1% increments are OK with me. Thanks again.

The heatsink on the Ryzen 3600 that reports Tdie and Tctl at 95C is only moderately warm to the touch. That was the case when I installed it.

So there are two possibilities: the heatsink is not making good contact to the chip, or else the reading is wrong. I will find out soon.

EDIT: The paste is spread out properly and sticking fine. It must be that the Ryzen 3600 reports the temps differently, or else is interpreted wrong. That is my latest build by the way, put together within the last month.

One option to cool your processor down a bit is to run it at base frequency using the cTDP and PPL (package power limit) settings in the bios. Both are set at auto in the "optimized defaults" bios setting. AMD and the motherboard manufacturers assume we are gamers or enthusiasts that want to automatically overclock the processors to the thermal limit.

The computers of ServicEnginIC are approx. 10% slower than mine. His CPUs are Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz and Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, mine are two AMD Ryzen 5 2600 Six-Core Processors.
Might it be that the Wrapper is slower on slower CPUs and therefore slows down the GPUs?

I have similar experiences with my hosts.

Thanks, but I believe you misread me. The CPU is fine. The measurement is wrong.

Damn! Wishful thinking!

How about 4.75. To many numbers on my screen
It's because it shows 4075 and then I automatically drop in the . at 2 places not realizing my mistake!

As far as temperature goes, I am only reporting the CPU temp at the sensor point.
I have sent a webform to Arctic asking them what the temp would be at the radiator after passing by the CPU heatsink. The air temp of the exhaust air does not feel anywhere near 80. I would put it down around 40C or less.

I will see what they say and let you know.

Tony - I keep getting this on random tasks
unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
13:11:40 (25792): wrapper (7.9.26016): starting
13:11:40 (25792): wrapper: running acemd3.exe (--boinc input --device 1)
# Engine failed: Particle coordinate is nan
13:37:25 (25792): acemd3.exe exited; CPU time 1524.765625
13:37:25 (25792): app exit status: 0x1
13:37:25 (25792): called boinc_finish(195)

It runs 1524 seconds and bombs.
What's up with that?

It also appears that BOINC or the task is ignoring the appconfig command to use only my 1050. I see another task that is starting on the 1050 and then jumping to the 650 since the 1050 is tied up with another project.

The temps are correct for the Ryzen and Ryzen+ cpus, but the k10temp driver which is stock in Ubuntu didn't get the change needed to accommodate the Ryzen 2 cpus with the correct 0 temp offset. That only is shipping in the 5.3.4 or 5.4 kernels.

Tony - I keep getting this on random tasks
unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
13:11:40 (25792): wrapper (7.9.26016): starting
13:11:40 (25792): wrapper: running acemd3.exe (--boinc input --device 1)
# Engine failed: Particle coordinate is nan
13:37:25 (25792): acemd3.exe exited; CPU time 1524.765625
13:37:25 (25792): app exit status: 0x1
13:37:25 (25792): called boinc_finish(195)

It runs 1524 seconds and bombs.
What's up with that?

It also appears that BOINC or the task is ignoring the appconfig command to use only my 1050. I see another task that is starting on the 1050 and then jumping to the 650 since the 1050 is tied up with another project.

# Engine failed: Particle coordinate is nan

It also appears that BOINC or the task is ignoring the appconfig command to use only my 1050.

I've had a couple of the NaN errors. One where everyone errors out the task and another recently where it errored out after running through to completion. I had already removed all overclocking on the card but it still must have been too hot for the stock clockrate. It is my hottest card being sandwiched in the middle of the gpu stack with very little airflow. I am going to have to start putting in negative clock offset on it to get the temps down I think to avoid any further NaN errors on that card.

I've had a couple of the NaN errors. One where everyone errors out the task and another recently where it errored out after running through to completion. I had already removed all overclocking on the card but it still must have been too hot for the stock clockrate. It is my hottest card being sandwiched in the middle of the gpu stack with very little airflow. I am going to have to start putting in negative clock offset on it to get the temps down I think to avoid any further NaN errors on that card.

http://www.gpugrid.net/show_host_detail.php?hostid=147723
http://www.gpugrid.net/show_host_detail.php?hostid=482132
...
Might it be that the Wrapper is slower on slower CPUs and therefore slows down the GPUs? Is this the experience from other users as well?

http://www.gpugrid.net/show_host_detail.php?hostid=147723
http://www.gpugrid.net/show_host_detail.php?hostid=482132
...
Might it be that the Wrapper is slower on slower CPUs and therefore slows down the GPUs? Is this the experience from other users as well?

that's really interesting: the comparison of above two tasks shows that the host with the GTX1660ti yields lower GFLOP figures (single as well as double) as the host with the GTX1650.
In both hosts, the CPU ist the same: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz.

And now the even more surprising fact: by coincidence, exactly the same CPU is running in one of my hosts (http://www.gpugrid.net/show_host_detail.php?hostid=205584) with a GTX750ti - and here the GFLOP figures are even markedly higher than in the abeove cited hosts with more modern GPUs.

So, is the conclusion now: the weaker the GPU, the higher the number of GFLOPs generated by the system?

Damn! Wishful thinking!

How about 4.75. To many numbers on my screen
It's because it shows 4075 and then I automatically drop in the . at 2 places not realizing my mistake!

As far as temperature goes, I am only reporting the CPU temp at the sensor point.
I have sent a webform to Arctic asking them what the temp would be at the radiator after passing by the CPU heatsink. The air temp of the exhaust air does not feel anywhere near 80. I would put it down around 40C or less.

I will see what they say and let you know.

Tony - I keep getting this on random tasks
unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
13:11:40 (25792): wrapper (7.9.26016): starting
13:11:40 (25792): wrapper: running acemd3.exe (--boinc input --device 1)
# Engine failed: Particle coordinate is nan
13:37:25 (25792): acemd3.exe exited; CPU time 1524.765625
13:37:25 (25792): app exit status: 0x1
13:37:25 (25792): called boinc_finish(195)

It runs 1524 seconds and bombs.
What's up with that?

It also appears that BOINC or the task is ignoring the appconfig command to use only my 1050. I see another task that is starting on the 1050 and then jumping to the 650 since the 1050 is tied up with another project.

# Engine failed: Particle coordinate is nan

Two issues can cause this error:
1. Error in the Task. This would mean all Hosts fail the task. See this link for details: https://github.com/openmm/openmm/issues/2308
2. If other Hosts do not fail the task, the error could be in the GPU Clock rate. I have tested this on one of my hosts and am able to produce this error when I Clock the GPU too high.

It also appears that BOINC or the task is ignoring the appconfig command to use only my 1050.

One setting to try....In Boinc Manager, Computer Preferences, set the "Switch between tasks every xxx minutes" to between 800 - 9999. This should allow the task to finish on the same GPU it started on.
Can you post your app_config.xml file contents?

What you posted is a mix of app_config.xml and cc_config.xml.
Be so kind as to strictly follow the hints and examples on this page:
https://boinc.berkeley.edu/wiki/Client_configuration