As I said. We are currently compiling the Windows version.

GDF

might as well compile it for CUDA 11.8 to bring Ada (40-series) support.

---

大家好！ 我在中国上海 如何让GPU 工作在百分之一百的状态 我发现在运行时GPU 一直在百分之30左右！[img][/img]

这个情况对于这个Python程序很正常，这个python程序用更多的CPU，而不是GPU。GPU的使用会被CPU限制。如果你同时运行两个任务，可以提高GPU的使用。但是在用这个Python程序的时候，你无法让GPU达到百分之百的状态。

---

我Nvidia能到80%。我也同时在运行其他的CPU（20%）和Intel GPU（97%）项目。电源调成最佳性能后，CPU到50%。Intel i7 12代。

Looking around I see the present batch of protein ligand sims are crashing... DARNIT!

process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
22:58:08 (3209098): wrapper (7.7.26016): starting
22:58:25 (3209098): wrapper (7.7.26016): starting
22:58:25 (3209098): wrapper: running /bin/bash (run.sh)
/bin/bash: run.sh: No such file or directory
22:58:26 (3209098): /bin/bash exited; CPU time 0.001795
22:58:26 (3209098): app exit status: 0x7f
22:58:26 (3209098): called boinc_finish(195)

anything else found?

---

"Together we crunch
To check out a hunch
And wish all our credit
Could just buy us lunch"

Piasa Tribe - Illini Nation

Looking around I see the present batch of protein ligand sims are crashing... DARNIT!

process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
22:58:08 (3209098): wrapper (7.7.26016): starting
22:58:25 (3209098): wrapper (7.7.26016): starting
22:58:25 (3209098): wrapper: running /bin/bash (run.sh)
/bin/bash: run.sh: No such file or directory
22:58:26 (3209098): /bin/bash exited; CPU time 0.001795
22:58:26 (3209098): app exit status: 0x7f
22:58:26 (3209098): called boinc_finish(195)

anything else found?

if someone can preserve the data files and slot directory before it gets uploaded and subsequently wiped from your system, should be easy to figure out what's wrong.

my guess is they didn't name that run.sh file properly (via open_name probably), or didnt add a task to extract the file in the wrapper config file (jobs.xml), or something along those lines.

---

actually I have some on my system so i took a look.

there appear to be many things wrong.

the job.xml file is calling just tar, with no reference to what tar is. this should probably be /bin/tar to use the system tar.

the extracted run.sh script looks woefully lacking in detail. i can see it trying to call python and conda from 'bin/' but that is not included in the input package and will fail. the input tarball only includes some text/config files and not the whole python package.

---

What app exactly?

What app exactly?

the new free energy one ('ATM' moniker). using the wrapper to call the run.sh script.

also it would be a good idea to add a checkbox for this app in project preferences. this app showed up with no warning and no announcement from the project and no way to prevent it it seems. I'm not sure if it's marked as beta or not.

---

Yes, we should have made a beta, but this app is not related to this thread.

Yes, we should have made a beta, but this app is not related to this thread.

you're right, but there is no announcement thread for this app, so no where else appropriate in the News section to get your attention about it.

---

Soon we will announce it. This is just testing to see if it works which should have been done on a beta app.

I expect tons of workunits using this app. Soon I will introduce a new postdoc running the simulations.

g

interesting to see that Ada "should" run on the Ampere cubins. I know the app has an architecture compatibility check, and it may fail there even if it could otherwise work.

you could also consider compiling your apps with the PTX version for forward compatibility

like this:
-gencode=arch=compute_86,code=sm_86
-gencode=arch=compute_86,code=compute_86

and the user can set the environment variable as needed. or you could set it in the wrapper config file

---

I am successfully running the current ACEMD_3 tasks on a GTX980ti, on a Quadro P5000, and on two RTX3070.
However, they fail on a GTX1650 after a few seconds:

https://www.gpugrid.net/result.php?resultid=33263379
https://www.gpugrid.net/result.php?resultid=33263343

can anyone tell me what might be the reason?

As a first, you can try resetting GPUGRID project at failing host.
But probably the reason is 4GB RAM being too short for executing these tasks.

...
But probably the reason is 4GB RAM being too short for executing these tasks.

that's what I am guessing, too.
However, I was closely watching the RAM usage (via MemInfo) when the tasks started: at the moment the task crashed, about 2 GB were still free.
Further, for the tasks running on the other hosts mentioned above, the Windows tasks manager shows a RAM usage between 60MB and 400MB per task.
Maybe the CPU Intel Core2 Duo E7400 @ 2.80GHz is too old for these tasks?
(However, some other GPU projects like Einstein, WCG and Primegrid are running well).

...
But probably the reason is 4GB RAM being too short for executing these tasks.

that's what I am guessing, too.
However, I was closely watching the RAM usage (via MemInfo) when the tasks started: at the moment the task crashed, about 2 GB were still free.
Further, for the tasks running on the other hosts mentioned above, the Windows tasks manager shows a RAM usage between 60MB and 400MB per task.
Maybe the CPU Intel Core2 Duo E7400 @ 2.80GHz is too old for these tasks?
(However, some other GPU projects like Einstein, WCG and Primegrid are running well).

i could very well be that the CPU is too old. it does not support AVX extensions for example, and if the application is built with this requirement then that could be a reason.

---

it could very well be that the CPU is too old. it does not support AVX extensions for example, and if the application is built with this requirement then that could be a reason.

perhaps one of the GPUGRID people could tell me if this is the case?

Just had one and it failed after 26 seconds on my 4090