I'm still running SoG Build 3401 on main. Any real reason to upgrade it to SoG Build "whatever the latest version is"?

New one fixes bug that could result in computation errors with GPUs with many CUs on some task. If you don't see such computation errors then perhaps you can stay with older one.

---

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

I'm still running SoG Build 3401 on main. Any real reason to upgrade it to SoG Build "whatever the latest version is"?

New one fixes bug that could result in computation errors with GPUs with many CUs on some task. If you don't see such computation errors then perhaps you can stay with older one.

Thank you Raistmer. I have no such computation errors at all. I'll stay with 3401.

Running SoG r 3430 on Main.

With the MESSIER guppi, they are slower than the cuda 50

Running SoG r 3430 on Main.

With the MESSIER guppi, they are slower than the cuda 50

Any links for analyze ?

---

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

24-Apr-16 13:57:39 | SETI@home Beta Test | Requesting new tasks for Intel GPU
24-Apr-16 13:57:39 | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
24-Apr-16 13:57:39 | SETI@home Beta Test | [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 devices
24-Apr-16 13:57:39 | SETI@home Beta Test | [sched_op] Intel GPU work request: 255793.03 seconds; 1.00 devices
24-Apr-16 13:57:43 | SETI@home Beta Test | Scheduler request completed: got 0 new tasks
24-Apr-16 13:57:43 | SETI@home Beta Test | [sched_op] Server version 707

---

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

Eric's post from 18 April

I plan to make the mods to the scheduler to allow all GPUs to run GBT VLAR workunits this week. The mod will go to beta first. We may have to restrict by GPU model if there are problems.

My Intel GPU has ceased receiving any workunits, either ALFA or GBT. Not sure why that would be.

Hi Eric

I'm guessing you just didn't have time to get to this last week, in which case not a problem, I'll wait :-) However, if you did make a change it doesn't seem to have worked. I've got a couple of hosts which keep asking for Intel GPU workunits but they haven't had anything in a while now.

No plan to pass 8.12 to production to Seti@Home??

No plan to pass 8.12 to production to Seti@Home??

yep, there are such plans. Next week or maybe after.

---

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

Tablet attached to SETI main:

http://setiathome.berkeley.edu/show_host_detail.php?hostid=7936570

<core_client_version>7.0.36</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable
setiathome_v8 8.00 Revision: 3300 arm-linux-androideabi-g++ (GCC) 4.8
libboinc: BOINC 7.7.0

Work Unit Info:
...............
WU true angle range is : 0.392394
features: swp half thumb fastmult vfp edsp neon vfpv3
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum 8.593220 0.00000
neon_ChirpData 262.093220 0.00252
fftwf_transpose 107.415254 0.00000
opt NEON folding 34.372881 0.00000
SIGSEGV: segmentation violation

Exiting...

</stderr_txt>
]]>

---

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

Eric's post from 18 April
My Intel GPU has ceased receiving any workunits, either ALFA or GBT. Not sure why that would be.

Hi Eric

I'm guessing you just didn't have time to get to this last week, in which case not a problem, I'll wait :-) However, if you did make a change it doesn't seem to have worked. I've got a couple of hosts which keep asking for Intel GPU workunits but they haven't had anything in a while now.

I'm not sure if it's just Intel GPUs - I only have a couple of APU-based AMD GPUs available for S@h Beta for the time being and they have had zero work since 17th April.

Maybe something unintended happened in the scheduler change?

It looks like it's going to be an all or nothing change, at least for now. GPUs on beta should now be getting GBT VLAR (but not Arecibo VLAR).

There's definitely a problem with the scheduler that is preventing Intel GPUs from getting any work.

---

It looks like it's going to be an all or nothing change, at least for now.

My C-60 low-end (if not AMD lowest end one) able to crunch VLAR with current defaults.
I would not enable VLAR for NV CC1.x cards though.

---

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

Thanks, Eric. Seem to be getting something now, and the 'unsent' figure on the status page is going down.

Since GBT is primarily VLAR, it makes sense to allow VLAR WUs there, I think. VLAR WUs are still slow - nearly twice as long on as non-VLAR WUs on my AMD GPUs - and almost as long as the CPU part of the APUs. But between that and no tasks to work on, I'll take the VLAR WUs.

I have Ontario/Zacate APUs working on S@h beta, same generation as Raistmer's C-60, both faster and slower models.

There's definitely a problem with the scheduler that is preventing Intel GPUs from getting any work.

My host 72559 started picking up work for Intel GPU (Windows, under Anonymous Platform) at 4 May 2016, 3:45:52 UTC.

Eric J Korpela wrote:

It looks like it's going to be an all or nothing change, at least for now. GPUs on beta should now be getting GBT VLAR (but not Arecibo VLAR).
(...)

I don't understand why GBT .vlar tasks need to be send to GPUs.

Very bad performance on GPU, like I wrote in message 58001 here in this thread.

On 1 CPU-Core of 12 of the Intel Xeon E5-2630v2 CPUs:
24ap10ad.18110.221515.4.31.31_0 / AR=0.391145 = CPU time = 1 hours 36 min 21 sec
blc0_2bit_guppi_57403_69832_HIP11048_0006.29397.831.21.44.252.vlar_1 / AR=0.012257 = CPU time = 52 min 17 sec

On CPU the GBT .vlar task is shorter than a mid-AR task, nearly 1/2 the time as a mid-AR task.

On one AMD Radeon R9 Fury X VGA card:
24mr10ac.30923.19310.5.39.173_1 / AR=0.429040 = Run time = 5 min 59 sec
blc3_2bit_guppi_57451_20612_HIP62472_0007.22580.831.17.20.60.vlar_0 / AR=0.008175 = Run time = 17 min 22 sec

On GPU the GBT .vlar task much longer than a mid-AR task, nearly 3x the time as a mid-AR task.


With the currently mix of GBT and Arecibo tasks my PC crunch happily 24/7 at Main (as example of currently very fast PC).
Currently top host #4 at Main.
(Before the PC crunched SETI-Beta and Einstein a few days, the RAC was ~ 117,500 @ SETI-Main (and still not reached max reachable RAC).)


In future the mix of available tasks at Main will change, just GBT tasks and not longer Arecibo tasks?
If the currently mix will continue, I don't understand all this - why it's needed to decrease the performance of the GPUs...

If this decision will be made at Main - I don't know if my PCs will continue to cruch SETI tasks (because it's wasted GPU performance (of/for SETI) - and/or withhold performance for other projects).
For sure - I'll not be the only one who will think about this...

Or the members will try to send the GBT .vlar tasks from their GPUs to their CPUs... (the currently tool can do this, or will be upgraded - or a new tool will come - for sure) - and CreditNew...

---

Why not use GPUs for .vlar, the penalty is not always that bad (see previous post) :

Macmini5,2 with AMD Radeon HD6630M (using default settings) :
AR=0.429040 has runtime of ca. 2 hours 25 minutes
AR=0.008175 has runtime of ca 2 hours 57 minutes

That's not much longer for the .vlar tasks. YMMV!

---

_\|/_
U r s

Maybe VLIW5-based Turks GPU doesn't suffer as badly as GCN-based GPUs. But VLAR tasks have always performed more poorly than non-VLAR tasks, so I also tend to prefer VLAR tasks on the CPU. Maximising use of resources and such.

In my point of view seti is an scientific project so all types of work should be sent to all devices.
Speed is no reason to avoid that.
AMD GPU`s have no issues at all running VLAR tasks.
OTOH as been seen at main during a VLAR storm lots of GPU`s will not get much work at all.

Maybe a switch to disable it manually in preferences would be a choice.
Seti@home v7 could be renamed to GreenBanks.
Shouldn`t be to much programming efforts.

---

With each crime and every kindness we birth our future.

I'm with you Mike, so long as the processor (whatever breed) is returning correct results then there is no need to preventing it running a particular type of work unit.
I think some are looking at the mess we had the other day when the vast majority of "guppi" units were failing due to a data issue and blaming GPUs for the problem - they were failing on CPUs as well...

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.