Now it's:

Before the .vlar storm:
SETI@home v8 8.12 windows_intelx86 (opencl_ati5_SoG_nocal)
SETI@home v8 8.12 windows_intelx86 (opencl_ati_nocal)
SETI@home v8 8.12 windows_intelx86 (opencl_ati5_nocal)
- all these apps had an 'Average processing rate' of ~ 510.

SETI@home v8 8.12 windows_intelx86 (opencl_atiapu_SoG)
SETI@home v8 8.12 windows_intelx86 (opencl_atiapu_sah)
- all these apps had an 'Average processing rate' of ~ 300.

After the .vlar storm:
SETI@home v8 8.12 windows_intelx86 (opencl_ati5_SoG_nocal)
SETI@home v8 8.12 windows_intelx86 (opencl_ati_nocal)
SETI@home v8 8.12 windows_intelx86 (opencl_ati5_nocal)
- all these apps have now an 'Average processing rate' of ~ 250 to 300.
Less than above mentioned.

So now my PC work more with the slow 'opencl_atiapu_*' apps.


AFAIK, the tasks here go also into the data base for the science. These tasks at Beta aren't 'test' tasks.

@ Eric, what's correct? ('test' or 'real' tasks)

Thanks.

---

So now my PC work more with the slow 'opencl_atiapu_*' apps.

Till time "VLAR storm" happened there were no good statistics to call APU builds definitely slower for your GPU (though quite possible they are).
All that APR thing too fluctuating, even w/o VLARs. It works in big numbers (maybe) but for single PC with active user offline benchmarking would be more effective eventually. APR from other side will serve to less active ones who will never run any benchmark by themselves.

---

News about SETI opt app releases: https://twitter.com/Raistmer

My offline benches have shown that APU versions are slightly faster on VLAR tasks but significantly slower on mid range tasks.
That should be the similar on FuryX.

---

With each crime and every kindness we birth our future.

I'll try to find a non-VLAR tape to get a better mix of work. Most of the GBT work from breakthrough will be VLAR. When Parkes observing happens, that could change, since the observing technique there is still under discussion.

---

Most of the GBT work from breakthrough will be VLAR...

:-(

I was trying different Apps with the VLARs the other day and found it appears the VLARs run better on NVs when the maxrregcount is set to 64 verses 32. Here's the difference between an App with it set to 32 and 64;
maxrregcount=32 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549498
maxrregcount=64 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549736
The only difference between those Apps is the maxrregcount.

maxrregcount here; http://setiathome.berkeley.edu/forum_thread.php?id=78569&postid=1772534#1772534

Most of the GBT work from breakthrough will be VLAR.

I still have hopes for Raistmer's OpenCl app, It makes good work of VLARs. And slightly faster with regular MBs

Can we have some "GUPPI" tasks here too?

---

News about SETI opt app releases: https://twitter.com/Raistmer

Can we have some "GUPPI" tasks here too?

Read my mind. Thanks.
Was wondering why no guppies have swum through here as yet?

---

If I can help out by testing something, please let me know.
Available hardware and software is listed in my profile here.

Most of the GBT work from breakthrough will be VLAR...

:-(

I was trying different Apps with the VLARs the other day and found it appears the VLARs run better on NVs when the maxrregcount is set to 64 verses 32. Here's the difference between an App with it set to 32 and 64;
maxrregcount=32 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549498
maxrregcount=64 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549736
The only difference between those Apps is the maxrregcount.

maxrregcount here; http://setiathome.berkeley.edu/forum_thread.php?id=78569&postid=1772534#1772534

Seems to be the same in Linux. The App compiled with maxrregcount=64 is much faster than the one with maxrregcount=32 with the Greenbank tasks.
maxrregcount=32 - http://setiathome.berkeley.edu/result.php?resultid=4855602154
WU true angle range is : 0.008804
Run time 45 min 58 sec
CPU time 2 min 27 sec
maxrregcount=64 - http://setiathome.berkeley.edu/result.php?resultid=4854499797
WU true angle range is : 0.008970
Run time 25 min 20 sec
CPU time 25 min 16 sec

I suppose the next step would be to compile a CUDA Baseline App with maxrregcount=64 and see how it preforms.

Most of the GBT work from breakthrough will be VLAR...

:-(

I was trying different Apps with the VLARs the other day and found it appears the VLARs run better on NVs when the maxrregcount is set to 64 verses 32. Here's the difference between an App with it set to 32 and 64;
maxrregcount=32 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549498
maxrregcount=64 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23549736
The only difference between those Apps is the maxrregcount.

maxrregcount here; http://setiathome.berkeley.edu/forum_thread.php?id=78569&postid=1772534#1772534

Seems to be the same in Linux. The App compiled with maxrregcount=64 is much faster than the one with maxrregcount=32 with the Greenbank tasks.
maxrregcount=32 - http://setiathome.berkeley.edu/result.php?resultid=4855602154
WU true angle range is : 0.008804
Run time 45 min 58 sec
CPU time 2 min 27 sec
maxrregcount=64 - http://setiathome.berkeley.edu/result.php?resultid=4854499797
WU true angle range is : 0.008970
Run time 25 min 20 sec
CPU time 25 min 16 sec

I suppose the next step would be to compile a CUDA Baseline App with maxrregcount=64 and see how it preforms.

Oh well, seems the Baseline App with maxrregcount=64 will only get you halfway to the promised land.
It's better than maxrregcount=32 but falls short of the "Special" App;
http://setiathome.berkeley.edu/result.php?resultid=4855881066
WU true angle range is : 0.008804
Run time: 35 min 1 sec
CPU time: 2 min 14 sec
The second task was the same, http://setiathome.berkeley.edu/result.php?resultid=4855867410

As with Streams, it would seem maxrregcount=64 only works with Compute Code 3.2 and above;

ptxas warning : Too big maxrregcount value specified 64, will be ignored
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z17cudaAcc_transposePfS_ii' for 'sm_20'
...
ptxas warning : Too big maxrregcount value specified 64, will be ignored
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z17cudaAcc_transposePfS_ii' for 'sm_30'
...
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z17cudaAcc_transposePfS_ii' for 'sm_32'
...
ptxas info : 0 bytes gmem
ptxas info : Compiling entry function '_Z17cudaAcc_transposePfS_ii' for 'sm_52'

There isn't a problem running the App on Devices lower than 3.2, the Compiler just ignores the setting on those Devices.
In Conclusion, to receive the best performance with VLARs on CUDA use the "Special" build with maxrregcount=64, but, 35 minutes is better than 45 minutes...

Raistmer wrote:

Can we have some "GUPPI" tasks here too?

You ask for 'guppi's...

And my PC get since 13 Apr 2016 ~13:30 UTC (since ~12 1/2 hours) just .vlar's...

;-)

:-(

---

Guppi are downloading to GPUs

Got a bunch of OpenCl_Nvidia_sah

Need to try the OpenCL_nvidia_SoG..

Did some beta testing before shutting down due to the warmer season approaching. Found one that would not process on my AMD 7990. https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8503271

If someone could look into this, I would appreciate it.

Hope everyone enjoys the rest of spring and summer. See you all late in the fall.

And for those down under please stay warm.

Did some beta testing before shutting down due to the warmer season approaching. Found one that would not process on my AMD 7990. https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8503271

If someone could look into this, I would appreciate it.

ERROR: Possible wrong computation state on GPU, host needs reboot or maintenance

This seems to be a class of error which has recently been reported on the main project message boards (OpenCL NV MultiBeam v8 SoG edition for Windows) and is currently being investigated. Useful to know that it applies to AMD as well as NV cards, which perhaps supports the diagnosis by Raistmer in the linked post.

Edit - another copy of that WU - task 23617765 - failed on Urs Echternacht's Linux host without going through the temporary exit/retry cycle.

Message from server: NVIDIA GPU: Upgrade to the latest driver to process tasks using your computer's GPU

That's a long standing problem in BOINC. That message is gerenated whenever any GPU version requires a higher or lower driver revision, regardless of whether any versions can be run.

I just started getting this message with my nvidia card. So I upgraded to the highest version, 341.95. I think it was already there, but just to be sure. Still getting the message.

I guess this means the server is requiring a lower version. What is the lover version required?

Thanks!

---

Dublin, California
Team: SETI.USA

What is the lover version required?

Thanks!

Now there's an existential question, if ever I read one!

You don't need a new version at all. I guess you must be talking about host 78651. That GeForce 210 card is very old, and now on legacy bug-fix only driver support from NVidia - driver versions for newer cards are up to something like 364.72.

The tight driver restrictions the server is complaining about are for the OpenCL applications, and you wouldn't want to run them on legacy NVidia hardware anyway. The CUDA applications you were running - until you aborted three tasks a couple of days ago - were running just fine, and should continue to run with your current driver, if you let them.

Did some beta testing before shutting down due to the warmer season approaching. Found one that would not process on my AMD 7990. https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8503271

If someone could look into this, I would appreciate it.

ERROR: Possible wrong computation state on GPU, host needs reboot or maintenance

This seems to be a class of error which has recently been reported on the main project message boards (OpenCL NV MultiBeam v8 SoG edition for Windows) and is currently being investigated. Useful to know that it applies to AMD as well as NV cards, which perhaps supports the diagnosis by Raistmer in the linked post.

Edit - another copy of that WU - task 23617765 - failed on Urs Echternacht's Linux host without going through the temporary exit/retry cycle.

I also received Errors running the App SETI@home v8 v8.10 (opencl_ati5_SoG_nocal) in Linux; SIGSEGV: segmentation violation
This Task also failed with the same SIGSEGV Error, http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=23613396. When I tried running the task again to see if it gave the same Error, BOINC refused to upload the file complaining about it couldn't open the file. I suppose the results are being marked read only again. So, I aborted the upload and then received an Invalid even though it appears the task ran correctly the second time without giving the SIGSEGV Error. Running the tasks with an older App version doesn't produce any Errors, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=76256

The CUDA applications you were running - until you aborted three tasks a couple of days ago - were running just fine, and should continue to run with your current driver, if you let them.

I have all GPU applications enabled in my preferences. Nothing has changed there. As you noticed, I was getting tasks no problem until recently. Now I am getting this error message from the server when I try to fetch work:

Message from server: NVIDIA GPU: Upgrade to the latest driver to process tasks using your computer's GPU

What changed on the server?

---

Dublin, California
Team: SETI.USA

They loaded a Green Bank Telescope data tape, which splits to mostly VLAR workunits. Those aren't sent to NVidia cards below Kepler (GTX 6xx). When data appropriate for processing on your hardware is available again, you will be eligible to receive it, despite what the message about driver versions is saying.

They loaded a Green Bank Telescope data tape, which splits to mostly VLAR workunits. Those aren't sent to NVidia cards below Kepler (GTX 6xx). When data appropriate for processing on your hardware is available again, you will be eligible to receive it, despite what the message about driver versions is saying.

Ah! Got it.

Curious, does this also apply to Intel HD graphics on OSX? They have also stopped getting tasks.

---

Dublin, California
Team: SETI.USA