An important issue I've noted after crunching these GPUGrid units in my Ubuntu 16.04 hosts, not in 18.04 ones, is that the rest of BOINC GPU projects (and folding#home) fail with error when trying to crunch. I tested with Amicable, Einstein and FAH.

I've had to reinstall NVIDIA drivers and restart to get things working again. A matter of libraries and links I guess.

I added GPUGrid to the projects list on one of my machines two years ago, I've never received a work unit. Other GPU projects are not having any trouble. Removed now.

---

I added GPUGrid to the projects list on one of my machines two years ago, I've never received a work unit. Other GPU projects are not having any trouble. Removed now.

I checked your computer and it appears it has an AMD GPU which is not supported. Only Nvidia cards are supported. Here's the FAQ for the new app:

http://www.gpugrid.net/forum_thread.php?id=5002#52865

Some years ago there was a AMD application and is still possible to check the box for AMD wu's in the GPUGRID preferences.
Maybe there will be less confusion if this check-box is removed ..

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

The limit is 2 per GPU. I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

It is a little ironic that a project specially for GPU's supports less GPU's than other projects. Einstein, Milky Way, Seti, etc. no problem.

---

Any ideas when new workunits will be release?

---

I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

Tell me more !
Seti has the problem of not beeing always available and not having always wu's available, but the allowed runtime is quite long. So it makes sense to have a larger buffer, but this should only affect the Seti wu's.

I believe the limit is 16 per host. That is what I got on my 3 hosts. After that I received the "you have reached the limit of tasks in progress message"

The limit is 2 per GPU. I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

I didn't think that was the issue. I never received more than two tasks per gpu on the previous run of work units.

It depends on the project whether they recognize the spoofed gpus. Seti does and why I use it to keep the gpus fed during the ever longer Seti outages.

It may be that this run of work did recognize the spoofed gpus. But the math doesn't add up for the 4 hosts. Each host got 16 WU's. I have three 3 card hosts and one 4 card host. One 3 card host got nothing because it primarily is an Einstein machine and I got nothing but gpu cache is full for a GPUGrid request.

Except for the Einstein host, all the other hosts are spoofed with either 21 or 32 gpus. By your math I should have only received 8 tasks on the 4 card host or 64 tasks. I did neither. It appears to have been fixed at 16 for each host. As I returned work, I kept getting my cache refilled to a 16 count for each host. I figured that was more likely from my global cache setting.

I see your computers are set up to run Seti, where it is common to "spoof" the server into "thinking" you have 32 coprocessors/GPUs per rig.

Tell me more !
Seti has the problem of not beeing always available and not having always wu's available, but the allowed runtime is quite long. So it makes sense to have a larger buffer, but this should only affect the Seti wu's.

The coproc_info.xml file that is created by the client controls the number of gpus detected.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

The coproc_info.xml file that is created by the client controls the number of gpus detected.

Got it. THX !

This was the first piece of a larger batch of 14k WUs. It's (amazingly!) already complete. I'll need to process it to create new WUs. The purpose of the work is (broadly speaking) methods development, i.e. build a dataset to improve the foundation of future MD-based research (not just GPUGRID). More details may come if it works ;)

Thanks to everybody for contributing. Also special thanks to those taking care of providing answers to BOINC details.

For a serial process like this the optimum would be to only send one WU per GPU.

For a serial process like this the optimum would be to only send one WU per GPU.

not really; because what would happen then is that there always is some idle time between uploading/reporting the result of a task and downloading the next one.
Which means the GPU cools off for a (short) while and heats up once the new task starts being cruched.
If this happens several time per day, over a lenghty period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.
Hence, it's definitely better to have another task already waiting to start immediately after the previous one gets finished.

not really; because what would happen then is that there always is some idle time between uploading/reporting the result of a task and downloading the next one.
Which means the GPU cools off for a (short) while and heats up once the new task starts being cruched.
If this happens several time per day, over a lenghty period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.
Hence, it's definitely better to have another task already waiting to start immediately after the previous one gets finished.

+1

...the GPU cools off for a (short) while and heats up once the new task starts being cruched (sic).
If this happens several time per day, over a lengthy period of time, this so-called "thermal cycle" definitely shortens the lifetime of the GPU.

The degradation process for electronics is called electromigration. Flowing current while hot actually moves atoms. Where the conductors neck down, e.g. turning a sharp corner or going over bumps, the current density increases and hence the electromigration increases. This is an irreversible process that accelerates as the conductor chokes down and ultimately results in a broken line and failure.

Since GPUGrid is supply-limited one per GPU would assure that more hosts get a WU before hosts start getting additional WUs. Now that the WUs run in less than half the time two per GPU works well but folks still get left out.

The GPUGrid server is notoriously slow. If it were fast and they had over 10,000 WUs continuously available then one per GPU would be optimum.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

[/quote]

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Fortunately simple manipulation doesn't work, as this file is overwitten by the BOINC manager at startup.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Fortunately simple manipulation doesn't work, as this file is overwitten by the BOINC manager at startup.

You can prevent the coproc file from been overwritten by BOINC.

Manipulate that file and you can tell BOINC that you have as many as 64 gpus. But you can't exceed 64 as that is a hard limit in the server side code.

Please don't "fake" gpus as it will create WU "hoarding": it will deprive other users of work, and slow down our analysis (we sometimes have to wait for batches to be complete).

Fortunately simple manipulation doesn't work, as this file is overwitten by the BOINC manager at startup.

You can prevent the coproc file from been overwritten by BOINC.

Which may explain tasks failing with

# Engine failed: Illegal value for DeviceIndex: 2

i.e. they attempt to run on non-existent gpus.