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.

<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>

First, YEAH!!!!! A new GPU project! Cool and thanks!!!!

Driver version 4xx.xx (at least for winblows) is the first driver to include support for the 2000 series RTX GPUs, and at least initially, it severely hampered the performance of the 10-series cards. I do not think many of your 10-series users will be willing to try a 4xx.xx driver version anytime soon.

EDIT: I decided to do my homework (AFTER I have already run my mouth :D ), and perhaps just the first few 4xx.xx drivers hurt the 10-series, I guess I will be updating my driver now to find out for myself. :)

GTX 1060, only a couple of months old, running proprietary driver 390.116, the latest in the repositories. Thanks for your "insight".

I have some information regarding server load. I think a good measure of that is how many WUs are processed per hour. Here is an average, broken down by day:
Before Sprint (3-13): 3571 WUs/hr
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 5042 WUs/hr
Sat (3-16): 4311 WUs/hr
Sun (3-17): 6593 WUs/hr

On Friday, the current batch that had been running (14x11) ran dry and processing started on the next batch (14x12). The WUs in 14x12 average twice the run time as 14x11, so to compare apples to apples, I did a 2nd calculation where I double the WU rate for the 14x12 cases before adding to the 14x11 rate. This gives the following WU rates (this is what the numbers would have looked like if both batches had the same run times):
Thurs (3-14): 9329 WUs/hr
Fri (3-15): 6871 WUs/hr
Sat (3-16): 7930 WUs/hr
Sun (3-17): 10692 WUs/hr

I think the key point here is that the worst server load is at the start and end of the sprint. I'm not an expert on the strategies behind these competitions, but I assume it's due to bunkering up front and then holding back results until just before the finish. Anyways, the other point of interest is that the worst server load was about 3 times our typical load.