I have a teammate who has joined GPUGrid and is unable to get any work. His cruncher meets all the requirements.
This is his rig.
https://www.gpugrid.net/hosts_user.php?sort=rpc_time&rev=0&show_all=1&userid=552015

This is the output of work_fetch_debug in the Event Log. I don't see any reason why the schedulers respond with no work sent.

Just a FYI, the user has all the project configuration settings set correctly and matches mine to a T.

Resource share ---
Use CPU no
Use ATI GPU no
Use NVIDIA GPU yes
Run test applications? no
Is it OK for GPUGRID and your team (if any) to email you? yes
Should GPUGRID show your computers on its web site? yes
Default computer location ---
Maximum CPU % for graphics 20
Run only the selected applications
ACEMD short runs (2-3 hours on fastest card): no
ACEMD long runs (8-12 hours on fastest GPU): no
ACEMD3: yes
Quantum Chemistry (CPU): no
Quantum Chemistry (CPU, beta): no
Python Runtime: no
If no work for selected applications is available, accept work from other applications? no
Use Graphics Processing Unit (GPU) if available yes
Use Central Processing Unit (CPU) yes

Try setting resource share to something above zero just to get the project going.

He tried that already with a resource share of 100. Tried beta applications also.

Still not getting any work from a request.

I think that the only two lines in there that have any meaning are:

I think that the only two lines in there that have any meaning are:

Fri 21 Feb 2020 02:45:29 PM EST | GPUGRID | [sched_op] NVIDIA GPU work request: 5584896.00 seconds; 64.00 devices
Fri 21 Feb 2020 02:45:30 PM EST | GPUGRID | Scheduler request completed: got 0 new tasks

He asked for work, and I think we must regard that as a refusal, rather than a lack of availability.

Unfortunately, at this project we don't get the rejection letter with a checklist of possible reasons at the bottom that some projects send out. So we'll have to turn detective.

We know

* NVIDIA GeForce RTX 2080 (8192MB) driver: 420.69
* Linux Ubuntu

And not much else that the server will want to check. Version of CUDA available? Compute Capability? To be honest, I don't know - but I'm wondering if Turing cards are yet supported under Linux?

I see that your friend's host ID # 524248 is showing "[64] NVIDIA GeForce RTX 2080 (8192MB) driver: 440.59"
Perhaps there is a new protection at server for not to attend requests for systems with such high amount of GPUs (?)
Please, try instructing this new user for his system to reflect its true number of GPUs for a while, to test wether it corrects the problem...
Toni kindly requested at this post for not using this kind of practices.

Try a reset of the project. Force it to send a test unit to see if the GPUs are viable.
____________

I see that your friend's host ID # 524248 is showing "[64] NVIDIA GeForce RTX 2080 (8192MB) driver: 440.59"
Perhaps there is a new protection at server for not to attend requests for systems with such high amount of GPUs (?)
Please, try instructing this new user for his system to reflect its true number of GPUs for a while, to test wether it corrects the problem...
Toni kindly requested at this post for not using this kind of practices.

Hi guys, I'm the guy who was having issues. I finally was able to get some work and earn credit so I can actually post.

I tried resetting the project, but that did not work. still gave the same message that no tasks are available.

Then I removed my custom edits and let BOINC re-generate my coproc_info.xml with the correct number of GPUs [7]. It then downloaded some WUs and processed them.

I will have to play around with some things, I see that Keith uses the spoofing also without any detriment, so maybe something just wasnt right in my coproc file.


second issue, GPUGrid doesnt seem to play nicely with Einstein when they are both set to 0 resource share. Basically I want to run them BOTH as a backup, so that when SETI runs out, they share the backup load equally. is that possible? right now, I was only able to download GPUgrid work if I suspended Einstein.

Glad you finally got work Ian. So how would that work if both Einstein and GPUGrid has resource share of zero when Seti runs out of work.

Who gets the first shot at work? Is it based on where each project comes out in the alphabet. That seems the case with my 4 project hosts. Einstein goes first, then GPUGrid, then Milkyway and finally Seti when all the projects update at the same time or when you first fire up BOINC.

Or is it the project with the most REC deficit? I would think that is what is supposed to happen. But Einstein will always send more work than you want unless you set a really small cache size. And if it gets to the schedulers first it will fill up your hard drive space allocation and prevent the other projects from getting work.

That is what was occurring on my dual Einstein/GPUGrid host. GPUGrid never could get work because the gpu cache was always full with Einstein. Only when there was a brief outage at Einstein and the gpu cache had dwindled down did GPUGrid get a chance to download work. And once that happened . . . . then GPUGrid commandeered the gpus totally because it had to work off a huge REC deficit to Einstein.

Maybe the servers thought that 64 gpus was out of bounds.

While 24 or 32 spoofed gpus is acceptable.

Glad you finally got work Ian. So how would that work if both Einstein and GPUGrid has resource share of zero when Seti runs out of work.

Who gets the first shot at work? Is it based on where each project comes out in the alphabet. That seems the case with my 4 project hosts. Einstein goes first, then GPUGrid, then Milkyway and finally Seti when all the projects update at the same time or when you first fire up BOINC.

Or is it the project with the most REC deficit? I would think that is what is supposed to happen. But Einstein will always send more work than you want unless you set a really small cache size. And if it gets to the schedulers first it will fill up your hard drive space allocation and prevent the other projects from getting work.

That is what was occurring on my dual Einstein/GPUGrid host. GPUGrid never could get work because the gpu cache was always full with Einstein. Only when there was a brief outage at Einstein and the gpu cache had dwindled down did GPUGrid get a chance to download work. And once that happened . . . . then GPUGrid commandeered the gpus totally because it had to work off a huge REC deficit to Einstein.

Maybe the servers thought that 64 gpus was out of bounds.

While 24 or 32 spoofed gpus is acceptable.

No I don't run any project as backup. They all get a standard resource share.

I have never seen Einstein obey the standard BOINC protocols for work allotment.

They don't run any server software that is current. Getting to be almost ten year old server software by now.

Keith has started to do what I do. Dedicated machines for certain projects.

So setting "0" resource share on both GPUGrid and Einstein results in only Einstein tasks downloading and processing. Is that correct? If so, have you tried adding an app_config.xml file to the Einstein project folder restricting the number of max concurrent tasks to 3 or 4?

<app_config>
<project_max_concurrent>3</project_max_concurrent>
</app_config>

EDIT: I'm hoping the above app_config.xml file will limit Einstein to 3 GPUs and leave the other 4 to process GPUGrid tasks if they download

hmm maybe that would work. i'll have to play around with it.

but I think since I'm planning to run GPUGrid as a backup, on this host I'll just leave Einstein set to NNT, and only release it if GPUGrid doesnt have any work at the time.

I have 2 other hosts [7x RTX2070, 10x RTX2070] that run SETI(prime)/Einstein(backup) but one of them has all 7 of the GPUs on USB PCIe 3.0x1 risers (PCIe 3.0 x1/x1/x1/x1/x1/x1/x1). which is fine for SETI/Einstein, but looking at PCIe usage on GPUGrid from the 2080 system, it looks to need at least a PCIe 3.0 x4 link. I'm observing ~20% PCIe use on a 3.0x16 link and ~40% use on a 3.0x8 link, meaning anything less than a 3.0x4 link will introduce a bottleneck. this 7x 2080 system has all cards plugged into the board with 3.0 x16/x8/x8/x16/x8/x8/x8 links respectively thanks to some clever PLX switches integrated to the motherboard.

the other system has 8 GPUs on a 3.0x8 link each, and 2 on USB risers (PCIe 3.0 x8/x8/x8/x8/x8/x8/x8/x8/x1/x1) I could probably play around with the gpu_exclude flag but it might be easier to just dedicate the one system to SETI(prime)/GPUGrid(backup), and let the other 2 be SETI(prime)/Einstein(backup)