Thanks Erik and Demis

Don't worry too much about it, I was curious more than anything.

The card is still put in computers that are set up as a cheaper entry point and it is mainly used for doing BOINC.
It is my brothers computer so I will see if I can source a cheap 4060 or 5060 and get it too him, it will be better at the games he sometimes plays anyway.

Thanks again
Conan

I bumped up the rsc_fpops_bound in the template file just for good measure, so newer batches are allowed to run longer.

But one thing that's worrisome is that NumberFields uses the exact same template file and hasn't had this problem in many years. So I wonder if there's something else different between Gerasim and NumberFields server settings that is causing this, maybe a difference in version or a config parameter.

@Conan: Have you used this card on a NumberFields WU and does it exhibit the same behavior? Can you compare the "Measured floating point speed" under computer details between NumberFields and Gerasim to see if there is a big difference?

I see credit was recently doubled to 8,000 (and the average runtime also seems to have increased with it, though not quite doubled) and now decreased to 800. I'm not complaining, just curious about the reasoning.

The difference in average times on the CPU went from 1.5 hours for the DS15x11 WUs to 3 hours for the DS14x12 WUs (these are averages over 100 WUs, all on the same machine). This is the reason for the initial doubling. So it is approximate, and of course there is no guarantee the GPU times will scale the same, but it should be close.

Then, as discussed in another thread, the credits were way too high for CPUs. To bring them back in line, I had to scale them back down by 10. The cpu WUs are still paying almost 2x the original (from several weeks ago).

Here's the problem: The original crediting system could be majorly abused by GPUs, so we had to change it. CreditNew paid next to nothing, so now we are paying a fixed amount per WU. This is not ideal either, as GPUs and CPUs should be treated differently. I think the best solution will be to use CreditNew, but hack the validator code to scale up the payout for GPUs. That will take work though, and I'd rather spend my energy finishing the GPU apps.

How does the current credit/hour for the GPU compare to other projects?

I got a little sneaky solution for me.

I simply deleted this files as root:

/etc/OpenCL/mesa.icd and intel.icd

reboot. It's getting nomore errors.

At administration:
Could u send me some GPU-wus , please ?
It always "says" job cache full.

It was paying around 20 per run sec on my GTX 1080 which is better than many GPU apps but not crazy. Now it's only paying 0.08 per run sec, 1/250 of what it was which is crazy low. It's worse paying than Asteroids on a GPU. Einstein pays 5-7 per run sec.

Maybe I'll try CPU and see if the points are better than GPU payout. :(

edit: If there is no significant point (not number of WUs completion) gain over CPU app, it certainly defeats the purpose of creating GPU app in the first place. I know some of us crunchers are crazy about points rather than the number of WUs completion. Like Asteroid, maybe pay a fix credits for each WU completion which is what is important to NumberField project, rather than the point. In general, the points are to attract crunchers. My one cent.

lol, at least you guys are getting tasks. I just keep getting "got 0 new tasks".

I disabled cpu tasks, just to test the GPU versions. I am running driver 418.56 AND I have a compute 3.0 card. Are there any tasks or am I configured incorrectly?

Only errors here.
GTX645; newest drivers 418
Anyone can help?

PG PPS sieve works fine.

Yesterday was triple the output of the Formula BOINC Sprint's best day.

Unfortunately, I don't think those numbers are accurate, just based on the numbers of results coming back. It's correlated to the obscenely high GPU credits being awarded. Maybe it's time I change to "Credit New", from the current "Credit based on runtime"?

ok, see no quick way to install cuda 10.1 , version 9.1 is latest on Ubuntu 18.10.

ok, i'll try to install then Cuda 8 , very later this evening, maybe tomorrow and see.

nope, only the task report says:

Now starting the targeted Martinet search:
Error code 700: an illegal memory access was encountered file polDiscTest_gpuCuda.cu line 415.

Just low to mid 70% GPU util so I'm running 2x. Now mid 90%.

<app_config>
  <app>
    <name>GetDecics</name>
     <gpu_versions>
      <gpu_usage>0.5</gpu_usage>
      <cpu_usage>0.1</cpu_usage>
     </gpu_versions>
  </app>
</app_config>

Interesting... I forgot you could control those things through the client. I just did the same thing. GPU is running a little hotter and my browser is a little sluggish... I might have to go back to running 1x.

So is 70% considered low? Should I try to optimize the utilization? During development, having too many blocks or threads per block caused crashes due to resource problems. I eventually settled on some values that seemed to work well, but maybe they are not optimal.

But I am pressing on with the OpenCL version first; I will worry about optimization later.