The server status page shows that there are tasks for "Short runs" and "Long runs", but I am not getting either of these tasks on my PC. The event log entries are:

GPUGRID | Sending scheduler request: To fetch work.
GPUGRID | Requesting new tasks for NVIDIA GPU
GPUGRID | Scheduler request completed: got 0 new tasks
GPUGRID | No tasks sent
GPUGRID | Tasks for CPU are available, but your preferences are set to not accept them

I did see another topic stating that CUDA 8.0 is required, but the BOINC logs suggest that I am running 9.1:

CUDA: NVIDIA GPU 0: GeForce GTX 760 (driver version 390.48, CUDA version 9.1, compute capability 3.0, 1992MB, 1545MB available, 2620 GFLOPS peak)

My account preferences are set to accept all applications, with "Use CPU" set to "no".

I am running on Ubuntu 18.04 LTS with Nvidia driver 390.48. Do I need to install a separate CUDA package to get GPU tasks?

I am running on Ubuntu 18.04 LTS with Nvidia driver 390.48. Do I need to install a separate CUDA package to get GPU tasks?

The server status page shows that there are tasks for "Short runs" and "Long runs", but I am not getting either of these tasks on my PC.

CUDA: NVIDIA GPU 0: GeForce GTX 760 (driver version 390.48, CUDA version 9.1, compute capability 3.0, 1992MB, 1545MB available, 2620 GFLOPS peak)

I am running on Ubuntu 18.04 LTS with Nvidia driver 390.48.

I had to add the nvidia PPA to get drivers to work with BOINC in 18.04. I don't recall if that was for OpenCL or CUDA. One was missing.

The older v8.49 app (CUDA6.5) supports cc3.0 cards, but there's only Windows version of this app. So you have to use Windows to make your cc3.0 card work with GPUGrid.

I have a like problem: I'm getting CPU tasks but no GPU.

Fedora-25, 7.8.4 x86_64-pc-linux-gnu, GeForce GTX 770

Do I have a configuration problem or as above there is nothing I can do to use my GPU?

Thanks

Currently there are no more "unsent" GPU work units.

Looks like the GPU well has run dry...
____________

so, this is really the CPUgrid.net ?????

so, this is really the CPUgrid.net ?????

I am still getting both CPU and GPU tasks on my main Linux box. A Linux laptop, with no GPU board, is getting CPU tasks.
Tullio
____________

so, this is really the CPUgrid.net ?????

so, this is really the CPUgrid.net ?????

somehow I would have expected some kind of statement from the GPUGRID people in reply to my posting above. Well, nothing so far :-(

A look at the current Server Status page shows interesting figures:

GPU tasks - unsent: 0; in progress: 1.761; users in last 24hrs: 924

CPU tasks - unsent: 44.723; in progress: 848; users in last 24hrs: 76

this alone shows the huge imbalance. 924 GPU users have no news tasks available, and 76 CPU users have 44.723 available.
What sense does this make?

There are about 12x more GPU users, not getting new taks. Whereas only 76 users are swamped with 44.723 tasks.

Where is the logic behind this?

Of course, everyone who wants go keep his/her GPU busy can choose from a variety of backup projects;
however, it should be clear to GPUGRID that there may be cases where crunchers do not return to GPUGRID once they satisfactorily participate in another project - particularly if there is a much better and more reliable availability of work.

After reading what is printed in the output directory of stderr.txt I would welcome a short explanation of what the program is doing. I have taken a structural chemistry course in my university years, talked with Enrico Clementi while working at Mondadori Scientific Publishing and followed some lectures on Density Functional Theory while at Trieste Area Research Park.
Tullio

The overview that Stefan gave is good enough for me. I expect we will have to await the details until the publication(s). There should be a series of them.

somehow I would have expected some kind of statement from the GPUGRID people in reply to my posting above. Well, nothing so far :-(

A look at the current Server Status page shows interesting figures:

GPU tasks - unsent: 0; in progress: 1.761; users in last 24hrs: 924

CPU tasks - unsent: 44.723; in progress: 848; users in last 24hrs: 76

this alone shows the huge imbalance. 924 GPU users have no news tasks available, and 76 CPU users have 44.723 available.
What sense does this make?

There are about 12x more GPU users, not getting new taks. Whereas only 76 users are swamped with 44.723 tasks.

Where is the logic behind this?

The overview that Stefan gave is good enough for me. I expect we will have to await the details until the publication(s). There should be a series of them.

Where can I find Stefan's post?
Tullio

Where can I find Stefan's post?

Thanks Erich56. Let me see if I have understood. We calculate the energy level of some molecules using Quantum Mechanical methods such as Density Functional Theory, then our results are fed to some neural networks which will perform the same calculations much faster. Is this right?
Tullio

We calculate the energy level of some molecules using Quantum Mechanical methods such as Density Functional Theory, then our results are fed to some neural networks which will perform the same calculations much faster. Is this right?

Recently the scientists at Berkeley SETI Research but also at SETI Institute,two different institutions, have used neural networks to analyze data from the Green Bank radio telescope, financed by Breakthrough Listen, to search for Fast Radio Bursts in the data (400 TB) accumulated at Green Bank and found many emission from a repeating source, the only repeated Fast Radio Burst source discovered so far.They had not been found by traditional methods. The origin of the FRB is still a mystery.
Tullio

Recently the scientists at Berkeley SETI Research but also at SETI Institute,two different institutions, have used neural networks to analyze data from the Green Bank radio telescope, financed by Breakthrough Listen, to search for Fast Radio Bursts in the data (400 TB) accumulated at Green Bank and found many emission from a repeating source, the only repeated Fast Radio Burst source discovered so far.They had not been found by traditional methods. The origin of the FRB is still a mystery.
Tullio

I am running SETI@home because there are many users who know a lot about computers and GPU boards. Some have put eight of them in a home made supercomputer, contrarily to the SETI original idea which was to exploit "unused cycles". Some of them are also my friends.
Tullio

... Some have put eight of them in a home made supercomputer ...

GPU tasks queue drying out again :-(

On the other hand, almost 170.000 CPU tasks for not more than 60 users.

Whole weekend again without WU's while an overload of CPU tasks are waiting to be crunched by a only a small packet of people.

We/I continuously bump into breaks where no WU's are available on GPU while an abundance of Quantum Chemistry CPU WU's are endlessly queuing.

As Erich66 pointed out already a number of times, I do not see any statement from the GPUGrid team.

To our disappointment.

Can anyone have the courtesy and take 5 minutes of time to respond please ?

Will QC CPU based WU's overtake GPU WU's in importance over time ?
Is it the purpose to abandon GPU based WU's ?

What is the strategy ?

Many thanks in advance for a prompt reply.

We/I continuously bump into breaks where no WU's are available on GPU while an abundance of Quantum Chemistry CPU WU's are endlessly queuing.

As Erich66 pointed out already a number of times, I do not see any statement from the GPUGrid team.

To our disappointment.

Will QC CPU based WU's overtake GPU WU's in importance over time ?
Is it the purpose to abandon GPU based WU's ?

I'm just glad there is pretty steady work during the week. There were times when GPUs could not be kept busy. Even if GPUGrid is not your main project it's good practice to have a backup project at 0% resource share.

Hi Zoltan,

Thanks for the reply, but I was hoping to rather get a statement from the GPUGrid team itself.

It may have been like that for years, agreed (and I confirm), but it doensn't mean that it should be like that :-)

Maybe it would be possbile to create big enough batches with maybe a little longer deadlines as to have sufficient WU's to also cover weekends and/or holiday periods.

There are some algorithms which enable you to predict future workload (I'm working in the contact centre industry and workforce load predictability is a big topic there).

And yes, I have Einstein and MilkyWay as backup projects, but it's a shame that I have to spend time on other projects while there are still uncountable protein interactions to be calculated.

So happy to have the CPU/GPU question solved, but still on my hunger about the WU scheduling approach.

Cheers & have a nice weekend !

It seems like we're again hitting a low in supply on GPU based WU's.
End of december and january (apart from the last week and a half) were
horrendous for GPU based WU's.

As we discussed and pointed out earlier in this post, there is an abundance
of QC WU's which is only being crunched by 1000 at a time while GPU is
crunched by 3000 simultaneously and hitting continuously a state of depletion
of GPU WU's.

Can some resources working on the QC WU's be redirected to GPU WU's please
so there are ample available and we can keep crunching without interruption ?

Current server statistics : 0 short runs, 0 long runs, 0 ACEMD, 148428 QC
Current crunching Wu's in progress : 730 short runs, 3035 long runs, 1250 QC.

Meaning that GPU based crunching has 4 times as many WU's being crunched compared to QC, while QC has 148428 WU's in queue and GPU WU's totally empty.

This has been the case for a while now (over half a year).
Where is the logic in this ?

Please reconsider your strategy and put more focus on GPU WU's...
And no, it's not my/our purpose to start crunching backup projects (although I do) and I have my personal reasons for that.

We would greatly appreciate to take our question into consideration :-)

Cheers,

BE.

Or even better : develop QC WU's for GPU ;-)