Message boards :
News :
SETI@home v8 beta to begin on Tuesday
Message board moderation
Previous · 1 . . . 47 · 48 · 49 · 50 · 51 · 52 · 53 . . . 99 · Next
Author | Message |
---|---|
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
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 |
![]() Send message Joined: 10 Mar 12 Posts: 1700 Credit: 13,216,373 RAC: 0 ![]() |
I'm still running SoG Build 3401 on main. Any real reason to upgrade it to SoG Build "whatever the latest version is"? Thank you Raistmer. I have no such computation errors at all. I'll stay with 3401. |
Send message Joined: 30 Dec 13 Posts: 258 Credit: 12,340,341 RAC: 0 ![]() |
Running SoG r 3430 on Main. With the MESSIER guppi, they are slower than the cuda 50 |
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
Running SoG r 3430 on Main. Any links for analyze ? News about SETI opt app releases: https://twitter.com/Raistmer |
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
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 |
Send message Joined: 12 Nov 10 Posts: 1149 Credit: 32,460,657 RAC: 1 ![]() |
Eric's post from 18 April 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. |
Send message Joined: 13 Dec 14 Posts: 14 Credit: 155,885 RAC: 0 ![]() |
No plan to pass 8.12 to production to Seti@Home?? |
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
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 |
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
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 |
Send message Joined: 2 Aug 12 Posts: 14 Credit: 7,429,417 RAC: 0 ![]() |
Eric's post from 18 April 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? |
![]() Send message Joined: 15 Mar 05 Posts: 1547 Credit: 27,183,456 RAC: 0 ![]() |
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. ![]() |
![]() ![]() Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 ![]() |
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 |
Send message Joined: 2 Aug 12 Posts: 14 Credit: 7,429,417 RAC: 0 ![]() |
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. |
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0 ![]() |
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. |
![]() Send message Joined: 7 Jun 09 Posts: 285 Credit: 2,822,466 RAC: 0 ![]() |
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... ![]() |
![]() Send message Joined: 18 Jan 06 Posts: 1038 Credit: 18,734,730 RAC: 0 ![]() |
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 |
Send message Joined: 2 Aug 12 Posts: 14 Credit: 7,429,417 RAC: 0 ![]() |
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. |
![]() ![]() Send message Joined: 16 Jun 05 Posts: 2530 Credit: 1,074,556 RAC: 0 ![]() |
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. |
Send message Joined: 21 Nov 12 Posts: 1015 Credit: 5,459,295 RAC: 0 ![]() |
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... |
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0 ![]() |
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. |
©2023 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.