Urs, maybe on MAC OS the .vlar tasks running 'well', but I guess 90 or 95% of all SETI PCs have Windows OS.


I made a thread at SETI-Main for a larger discussion.

---

...The other problem I identified in that post seven years ago, and which still applies today, is the sheer inefficiency of the code NVidia supplied at VLAR. Nobody's been able to solve that completely, and I for one would choose to use my NVidia GPUs for the work they're efficient at. "Four times the time, but only an extra 15% FLOPs" may not be the exact efficiency measure now, but it's still a poor use of the hardware.

On the newer nVidia cards, CC 3.2 and higher, Petri's code based on 'streams' is much better on the VLARs than the 'original' code. Somewhere around twice as fast on a nVidia 750Ti. There doesn't seem to be any problem with screen Lag either. Of course this doesn't help the compute code 3.0 and lower cards, but it does offer hope for the newer cards. Based on my tests the CUDA 'Special' App is about as fast as the OpenCL SoG App on a 750Ti.
Something to think about anyway.

Please remember that some people like to use their computers for other things foremost, and the scientific research is just the icing on the cake. The default settings, for both BOINC and SETI, have to be designed so they don't intrude on "normal use", whatever the hardware and whatever that 'normal' is for the user concerned.

From my point of view, unchanged since 15 Jan 2009, the main reason for not sending VLARs to NVidia GPUs (by default, at any rate) is the lagginess - poor screen usability while they are running. Until and unless the server scheduler can be programmed to recognise the characteristics of a 'laggy GPU', and avoid sending VLARs to those machines, I think we should proceed cautiously. Enabling user opt-in through preferences would be a good first step along the way.

The other problem I identified in that post seven years ago, and which still applies today, is the sheer inefficiency of the code NVidia supplied at VLAR. Nobody's been able to solve that completely, and I for one would choose to use my NVidia GPUs for the work they're efficient at. "Four times the time, but only an extra 15% FLOPs" may not be the exact efficiency measure now, but it's still a poor use of the hardware.

Therefore boinc has a setting don`t use GPU while computer is in use.

Like i said i would prefer the switch so everyone can choose on his own.

---

With each crime and every kindness we birth our future.

blc3_2bit_guppi_57451_20612_HIP62472_0007.22580.831.17.20.60.vlar_0 / AR=0.008175 = Run time = 17 min 22 sec

Link to this result please.

---

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

blc3_2bit_guppi_57451_20612_HIP62472_0007.22580.831.17.20.60.vlar_0 / AR=0.008175 = Run time = 17 min 22 sec

Link to this result please.

There's a search box...

Task 23610097

Urs, maybe on MAC OS the .vlar tasks running 'well', but I guess 90 or 95% of all SETI PCs have Windows OS.


I made a thread at SETI-Main for a larger discussion.

I had no issues running VLAR tasks on my HD 6870 with Windows 7. I believe the reason that send VLAR to GPUs was disabled was that it caused some NVIDIA GPUs to either crash or become unresponsive. So not sending VLAR tasks to all GPUs solved the issue for the lowest common denominator. If VLAR tasks no longer cause issues on systems, or the GBT VLARs don't have the same type of issue. Then it makes sense to once again send those tasks to all devices.

---

Unless explicitly directed to do otherwise by one of the developers you should always be using the version provided by the server for Beta.

I would love the change to crunch the GBT on my GPUs on Main.

Yes I'm aware that they take longer than a non-VLAR work unit but I don't think it's fair to compare a VLAR with a non-VLAR.

Better to compare CPU VLAR to GPU VLARs.

As such, the GPU takes half as long 21 minutes compared to the 43 min on my mega cruncher.

Yes, the credit aspect messes up things for everyone but if it's about getting the data crunched then doing it the fastest we can, I say let the GPUs run with them.

I would love the change to crunch the GBT on my GPUs on Main.

Yes I'm aware that they take longer than a non-VLAR work unit but I don't think it's fair to compare a VLAR with a non-VLAR.

Better to compare CPU VLAR to GPU VLARs.

As such, the GPU takes half as long 21 minutes compared to the 43 min on my mega cruncher.

Yes, the credit aspect messes up things for everyone but if it's about getting the data crunched then doing it the fastest we can, I say let the GPUs run with them.

+1
But would also like to be able to control that, on or off.

---

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

blc3_2bit_guppi_57451_20612_HIP62472_0007.22580.831.17.20.60.vlar_0 / AR=0.008175 = Run time = 17 min 22 sec

Link to this result please.

There's a search box...

Task 23610097

Thanks!

@Dirk.
Try to add -sbs 512 option to command line. How will it change speed of VLAR processing?

GPU with 64 CUs is not the same as GPU with let say ~20 CUs. It will starve on much more PulseFind kernel invocations than midrange one with default settings.
Hence such big performance drop that doesn't observable on less capable devices.
So lets try to find how defaults could be scaled to reduce this performance drop still conforming definition of "default stock" in terms of unattended non-intrusive use.

---

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

Urs, maybe on MAC OS the .vlar tasks running 'well', but I guess 90 or 95% of all SETI PCs have Windows OS.


I made a thread at SETI-Main for a larger discussion.

1) It's not OS but device performance issue. Your card needs much more parallelized work to stay busy than those Urs listed.

2) Not discussion but tuning needed. "Wider discussion" will not solve performance drop.

---

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

Urs, maybe on MAC OS the .vlar tasks running 'well', but I guess 90 or 95% of all SETI PCs have Windows OS.


I made a thread at SETI-Main for a larger discussion.

1) It's not OS but device performance issue. Your card needs much more parallelized work to stay busy than those Urs listed.

2) Not discussion but tuning needed. "Wider discussion" will not solve performance drop.

I disagree in this case but we should discuess this at Lunatics.
I notice performance drop on VLAR`s for more than a year now on all GCN based GPU`s i have tested so far.
And that`s quite a few.

---

With each crime and every kindness we birth our future.

I'm sad, disappointed, little upset... - because of a few things.

I don't understand why Eric (and/or other admins) want to send GBT .vlar tasks to GPUs.
With the currently mix of Arecibo and GBT tasks at Main, there is no problem to feed e.g. my PC (example for a fast PC) for 24/7.

Or Arecibo tasks will run out, just GBT tasks will come in future?
How will look the mix in future?

Also...
Until now I found noone with which I talked who could say, if the tasks here at Beta go into the data base for the science or not.
The admins worry if they would say, the tasks here are just test tasks and don't go into the data base for the science, that noone will participate here at Beta?

No statement of the admins to this questions.

I'm a hardcore SETIzen, build PCs just for SETI, pay the electricity bill and I'm with my heart here...
I think the project live and profit from this kind of members.
It's then not possibly to ask and expect answeres?
If I find myself not understood and ignored, it's understandable if the members leave the project?

I remember the past, wasn't I the starter of revolt at Main that VLAR tasks shouldn't be send to GPUs?
The related thread in the Main News Forum has been hidden later.
Then the admins decided to give the .vlar extension to the tasks and didn't send it to the GPUs.

I want to give SETI the max performance of my PC, GBT .vlar tasks on GPUs are decreasing of the performance.

If there will be not a checkbox for to un-/check 'GBT .vlar tasks to GPU (?)' in the project prefs, I guess, worry - I'll leave SETI.
Not a big deal for SETI, of course, I'm a realist ;-) ... - but I guess, worry, I'll be not the only one who will do this...

If the currently 'GPU -> CPU task send tool' will work with SETIv8, or not, then will come an upgrade or a new tool, this would be a hard work for me, I should need to let run it every few hours because of the very fast FuryX VGA cards... - this will be annoying... - and screw up CreditNew for me and the wingmen... - not a solution for my PC, but I guess for many others...


Please don't misunderstood my message, english isn't my 1st language, so maybe I didn't used the correct words - my heart was talking...

- - - - - - - - - -

Currently I use the r3430 ATI HD5 app at Main (with the permission of Raistmer).
I use -sbs 512 since a longer time, VHAR tasks didn't changed, but mid-AR tasks gone from around 6 mins down to around 5 mins 20 secs (no bench test, live).

I would like to make bench test runs (I guess - because after nearly 1 year it's still not possible to let run 2 WUs/GPU on my FuryX's with the currently available drivers - this will not change in future, now I could start to make bench test runs for to find opti cmdline settings for AP and MB), but until now I didn't found the correct tools on the Lunatics site.

I used:
MBbench 2.10
PG WU set v8 (all tasks without the VLAR task)
WisGen WUs.7z (the _WisGenA.wu)

For long time as I made AstroPulse bench test runs on my J1900 (iGPU + GT730) PC, I inserted the app with a few different cmdline settings (in BenchCfg.txt), after execution of the .cmd file the tool created the .wisdom file at (with) the 1st (cmdline line), and all other following cmdline (lines) settings the task (.wisdom creation) run were skipped, and then the 'real' bench test run started with the test tasks.

With the above mentioned MBbench 2.10 for SETI tasks, it don't create a .wisdom file automatically. (I don't know what to do with the files of 'MBBench v2.13' (it looks like it will suspend 3 CPU tasks and make GPU bench test?))

I used _WisGenA.wu, made a copy of it named it _WisGenB.wu - and this two tasks in the folder TestWUs.

Then this both tasks were used for to create the .wisdom file and all other files (*.bin_V7_*, .bin_*****VM).
Then the 3 'real' test tasks were calculated.
But the above mentioned tasks lasts just around 30 secs (hard to find time differences).


Could someone of the Lunatics crew make 'new' 'longer' bench test tasks (for fast GPUs)?
Maybe 2 mins VHAR, 4 mins mid-AR and 6 mins ('guppi') VLAR tasks?
So that they are good (and have everything) for to make bench test runs (on fast GPUs) for to find fastest cmdline settings. This would be very helpful and I would be very grateful.

Then I could make a bunch of bench test runs with (recommended/wanted) cmdline settings.


Thanks.

---

Arecibo has recorded very little data in 2016. Eventually we will be 90 or 100% breakthrough tasks.

---

Well, since the RAC is dropping like a stone on main, I might as well spend some 24/7 testing here on main with my main cruncher.

Let's see what it can achieve.

Edit: Running GPU tasks only with OpenCL settings from SoG on main:

-cpu_lock -sbs 256 -period_iterations_num 20 -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64 -instances_per_device 3

Same for both mb_cmdline-8.12_windows_intel__opencl_nvidia_sah.txt, and mb_cmdline-8.12_windows_intel__opencl_nvidia_SoG.txt

Let the fun begin.

I don't understand why Eric (and/or other admins) want to send GBT .vlar tasks to GPUs.
With the currently mix of Arecibo and GBT tasks at Main, there is no problem to feed e.g. my PC (example for a fast PC) for 24/7.

Or Arecibo tasks will run out, just GBT tasks will come in future?
How will look the mix in future?

Answer is given. It's no work or slow work choice. Not slow work or fast work one.

But the above mentioned tasks lasts just around 30 secs (hard to find time differences).

Indeed, existing PGv8 set is too fast for high-end cards.
So I would recommend for now to take one GUPPI VLAR task from here or main, to put it into bench and use it for tuning.
If VLAR is "our new future" then it make sence to do best optimization under very VLAR task.

---

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

No problems whatsoever running VLARs on my 980 with this command line options:

-cpu_lock -sbs 256 -period_iterations_num 20 -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64 -instances_per_device 3

The server/scheduler have decided that SoG is the fastest app (no surprise there). No screen lags ( no surprise there either, since I do not run the monitor on the 980, but on the INTEL Intel(R) HD Graphics 4600.

No other type of machine lags either, even if I run 3 VLARs at a time. Completion times of VLARs, acceptable.

Valid results of the 980 computer: http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=75292&offset=0&show_names=0&state=4&appid=

Release the Kraken on main :-)

Are you running 1 or 2 instances on the 980 Sten ?

---

With each crime and every kindness we birth our future.

Are you running 1 or 2 instances on the 980 Sten ?

As my command line states -instances_per_device 3.

3 instances it is, anything less is a waste of resources. I've tested SoG on main for a long time now. Over 25 thousand tasks finished.

4 is a little bit slower than 3, but it's really a toss-up. With lots of shorties, 4 instances is faster, but with a mix of ARs, 3 at a time is faster.

GTX980 temp is 62-65 C. However, that is with side off, and a table top fan pointing at the inner workings of the computer :-)

With the summer coming, that will not be enough though. This room will get at 30-32 C, and I have to crunch mostly from late evenings, and to maybe 9 in the morning. I have a portable AC, but it isn't worth the electicity cost to keep it running all day, just to be able to run SETI.

Just encountered a "finish file present too long" error on Arecibo mid-AR task 23790517 - it was sharing the GTX 970 with a guppi VLAR, running SoG r3430.

Timetable was

11:03:17 (40088): called boinc_finish(0)
08/05/2016 11:03:30 | SETI@home Beta Test | [sched_op] Reason: Unrecoverable error for task 24mr10ac.7768.9486.6.40.124_1
08/05/2016 11:03:35 | SETI@home Beta Test | Computation for task 24mr10ac.7768.9486.6.40.124_1 finished

So it looks as if there was an 18-second gap between calling finish and the app quitting, with BOINC pulling the plug at 13 seconds.

Just encountered a "finish file present too long" error on Arecibo mid-AR task 23790517 - it was sharing the GTX 970 with a guppi VLAR, running SoG r3430.

Timetable was

11:03:17 (40088): called boinc_finish(0)
08/05/2016 11:03:30 | SETI@home Beta Test | [sched_op] Reason: Unrecoverable error for task 24mr10ac.7768.9486.6.40.124_1
08/05/2016 11:03:35 | SETI@home Beta Test | Computation for task 24mr10ac.7768.9486.6.40.124_1 finished

So it looks as if there was an 18-second gap between calling finish and the app quitting, with BOINC pulling the plug at 13 seconds.

Hmm. Guess xj didn't totally drive a stake through the heart of that particular issue ... Personally, haven't had that since I loaded it ...

---

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