OpenCL MultiBeam for Windows, Linux and OS X updated. Please test thoroughly.
Message boards :
SETI@home Enhanced :
OpenCL MultiBeam for Windows, Linux and OS X updated. Please test thoroughly.
Message board moderation
| Author | Message |
|---|---|
 Raistmer Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0 
|
Update includes gradual improvements since last release (almost 2 year old now). And first-time introduced in stock sanity checks to prevent invalid results from GPUs "going mad" to validate against each other. These binaries (for all supported OSes) superseed currently available opt apps from last Lunatics pack and include per-device config support and oclFFT tuning abilities similar to last AstroPulse releases. News about SETI opt app releases: https://twitter.com/Raistmer ID: 54204 ·  |
 Send message Joined: 18 Jan 06 Posts: 1038 Credit: 18,734,730 RAC: 0 
|
Using this host i do not get work for the ATI/AMD GPU. BOINC 7.2.42 reports no CAL info for that GPU, preferences checked, if ATI GPU + CPU work fetch is allowed the host gets work only for CPU. Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | [work_fetch] set_request() for ATI: ninst 1 nused_total 0.000000 nidle_now 1.000000 fetch share 1.000000 req_inst 1.000000 req_secs 60480.000000 Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | [sched_op] Starting scheduler request Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | [work_fetch] request: CPU (0.00 sec, 0.00 inst) ATI (60480.00 sec, 1.00 inst) Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | Sending scheduler request: To fetch work. Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | Reporting 6 completed tasks Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | Requesting new tasks for ATI Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices Mi 20 Mai 2015 16:18:44 CEST | SETI@home Beta Test | [sched_op] ATI work request: 60480.00 seconds; 1.00 devices Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | Scheduler request completed: got 0 new tasks Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] Server version 707 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | Project requested delay of 7 seconds Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.19082.20062.140733193388035.16.216_5 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.29199.23334.140733193388035.16.191_5 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.19082.20062.140733193388035.16.114_7 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.19082.19653.140733193388035.16.146_5 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.29199.23334.140733193388035.16.171_4 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] handle_scheduler_reply(): got ack for task 08se12ab.19082.20062.140733193388035.16.140_4 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [work_fetch] backing off ATI 5575 sec Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] Deferring communication for 00:00:07 Mi 20 Mai 2015 16:18:49 CEST | SETI@home Beta Test | [sched_op] Reason: requested by project Mi 20 Mai 2015 16:18:49 CEST | | [work_fetch] Request work fetch: RPC complete _\|/_ U r s ID: 54205 · |
David S Send message Joined: 10 Sep 13 Posts: 1187 Credit: 2,791,507 RAC: 0 
|
Update includes gradual improvements since last release (almost 2 year old now). I'll turn loose my i7 on it. David signature sent back to alpha testing ID: 54209 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
Using this Host http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=72013, I can't receive any ATI MB work; Thu 21 May 2015 07:59:06 PM EDT | | Starting BOINC client version 7.2.33 for x86_64-pc-linux-gnu ID: 54222 · |
|
Send message Joined: 18 Jan 06 Posts: 1038 Credit: 18,734,730 RAC: 0
|
Note for rebuild : Use static lib ! http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=72274 Stderr output <core_client_version>7.2.33</core_client_version> <![CDATA[ <message> process exited with code 127 (0x7f, -129) </message> <stderr_txt> ../../projects/setiweb.ssl.berkeley.edu_beta/setiathome_7.06_x86_64-pc-linux-gnu__opencl_nvidia_sah: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory </stderr_txt> ]]> _\|/_ U r s ID: 54224 · |
|
Raistmer Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0
|
My host receives tasks for both ATi apps: SETI@home v7 7.06 windows_intelx86 (opencl_ati_cat132) Number of tasks completed 37 Max tasks per day 73 Number of tasks today 12 Consecutive valid tasks 40 Average processing rate 55.36 GFLOPS Average turnaround time 0.81 days SETI@home v7 7.06 windows_intelx86 (opencl_ati5_cat132) Number of tasks completed 3 Max tasks per day 36 Number of tasks today 10 Consecutive valid tasks 3 Average processing rate 25.35 GFLOPS Average turnaround time 1.11 days Should be only HD5 when going to main. News about SETI opt app releases: https://twitter.com/Raistmer ID: 54226 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
I'm still not getting any Ubuntu MB work, although I am getting AP work; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72013 It doesn't look like Urs is having any luck with his Linux host either. Any idea on how many stock 700 Mac CPU tasks you have to go through before getting the 7.05 (sse3) App? Is it like the AP (sse3) app where you had to go through about 60 of the slow tasks before receiving the sse3 tasks? So far I've only seen 1 host get the sse3 version, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=59702 I'm working on it, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63959 ID: 54230 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
Still not getting any ATI MBs on the Linux Host, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72013 Sat 23 May 2015 01:13:28 PM EDT | SETI@home Beta Test | Sending scheduler request: Requested by user. It appears not a single Mac OS X/64-bit Intel 7.05 (avx) task has been issued, 0 GigaFLOPS, and only 3 Mac OS X 7.05 (sse3) were issued to one host, 1 GigaFLOPS. http://setiweb.ssl.berkeley.edu/beta/apps.php The three 7.05 (sse3) tasks were about twice as fast as the v7 v7.00 tasks on that host but the server went back to sending the host v7 v7.00 tasks and hasn't sent any other v7 v7.05 sse3 tasks; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=59702 :-( ID: 54240 · |
|
Send message Joined: 18 Jan 06 Posts: 1038 Credit: 18,734,730 RAC: 0
|
Had to abort about 25 7.00 stock tasks to get to avx and sse3 plan class apps. All i can say for the moment these do run, nothing (out of overflows) finished so far. _\|/_ U r s ID: 54244 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
Yes, I broke down and starting hitting the Abort button as well and after 30 hits I finally received the SSE3 App. http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63959&offset=0&show_names=0&state=0&appid= Nice. ID: 54246 · |
|
Raistmer Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0
|
All those abortions just confirm that we can't rely on current implementation of BOINC's auto-selection feature, sadly. So, on main plan classes should be arranged in such manner that allows only seemed to fastest app for host to be sent, not all builds that would run on particular host. News about SETI opt app releases: https://twitter.com/Raistmer ID: 54248 · |
|
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0 
|
A user at BOINC reported an antivirus alert for the new v7.06 MB intel_gpu application. I've run it through virustotal, and I'm pretty sure it's the standard heuristic (behavioural) false alarm that Avast! is notorious for. Details at Malware Alert from Avast AV Software on Win 8.1 ID: 54249 · |
|
Raistmer Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0
|
Each time I read about "the wisdom of crowds" in AV field I recall famous sentence "millions of flies can't mistaken". Example: "change my software" fake. VirusTotal says it is "clean" while almost definitely it's fake app in best case or Trojan downloader. DrWEB and Avira say binary clear. So false alarm. News about SETI opt app releases: https://twitter.com/Raistmer ID: 54250 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
All those abortions just confirm that we can't rely on current implementation of BOINC's auto-selection feature, sadly. So, on main plan classes should be arranged in such manner that allows only seemed to fastest app for host to be sent, One other alternative is to just lower the Time estimates on the 705 CPU tasks. The SSE3 versions I received had an Estimate of 14 Hours. Since this was much higher than the APR of the stock 700s the server didn't want to send any 705s. I was able to complete the magic #11 just as the server had started sending me 700s again. As soon as the #11 was completed the server stopped sending the 700s and went back to sending 705 (sse3) tasks, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63959. If someone could just lower the 705 Estimate down to about One Hour instead of 14 I believe the server would respond appropriately. One Hour would still allow 20 hours before exceeding the time limit and I doubt any of the 705s would take over 20 hours. This is similar to the new AP CPU versions that had estimates of hundreds of hours on older CPUs causing CPU Panic back when APv7 was released. IMO, the time estimates are too high to allow the auto-selection feature to work correctly. What happened to Urs's Mini? Those results were extremely interesting. I couldn't wait to see it run a Shortie... ;-) ID: 54251 · |
|
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0
|
The trouble is, the server has no value for anything even resembling a 'time estimate'. It simply doesn't exist until the task reaches your computer: it's your computer which does the math. We have two values to play with - size and speed. Nothing else. "FPOPs" (floating point operations - a large number) divided by "Floating point operations per second" yields an answer in "seconds" - and that's your time estimate. The size of a task in FPOPs is fixed by the splitter. It doesn't change (apart from a fudge to do with anonymous platform) whatever application, processor or version it's processed with: it's inherent to the task. The speed of the device is the thing which changes (the way things are currently disorganised). CPUs and GPUs run at different speeds - that's fair enough. Different application versions run at different speeds - also fair enough, provided the measuring and monitoring is done properly. And we have transitional estimates for - notoriously - the first 10 tasks after any change in anything. I've complained about that many times over, but nothing ever happens. So, we have a number of choices - none of which is very appetising. 1) Eric (who does understand the problem) adds 'rewrite BOINC's time estimator to take account of lessons learned' to his seventeen thousand other day jobs. That's not a fair request. 2) We all gang up on David (who has the responsibility, but doesn't appear to understand the problem) until he fixes it. Five years of trying says that isn't going to happen either. 3) We write it ourselves. How are your coding skills, TBar? 4) We accept the offers of the other people who have offered to code it for us. 18 months ago, they offered. I see no code. 5) There is no plan 5. ID: 54252 · |
|
Raistmer Send message Joined: 18 Aug 05 Posts: 2423 Credit: 15,878,738 RAC: 0
|
more verbose please P.S. Actually, issue with wrong estimations of speed much more fundamental even than "time limit exceeded" issue. Given variability in run times between WUs and variability of WUs distribution over time it's hard not to get wrong estimate if app versions performance close enough. Especially if we don't want to run slower ones too long. In opposite case "proper" estimation will cost more than gain will be after its completion. News about SETI opt app releases: https://twitter.com/Raistmer ID: 54253 · |
|
Send message Joined: 2 Jul 13 Posts: 505 Credit: 5,019,318 RAC: 0
|
The trouble is, the server has no value for anything even resembling a 'time estimate'. It simply doesn't exist until the task reaches your computer: it's your computer which does the math. If it were possible, simply add a DIVIDE by 10 at the end of the current time estimate highlighted above. In my experience that would produce a much more accurate time estimate in both MB & AP. Also, in the instance where it is just a version upgrade as with the CPU MB App, simply use the host's existing APR from the current App for the new App. Problem Solved. If the APRs are the same, the Server will most likely send Both tasks instead of the one with the higher APR. That wasn't too difficult, was it. ID: 54255 · |
|
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0
|
more verbose please I'll leave them to speak for themselves. P.S. Actually, issue with wrong estimations of speed much more fundamental even than "time limit exceeded" issue. Agreed. It's fiendishly complicated: the problem isn't just the variability of runtime between tasks, but the variability of application efficiency for different datasets. For MB, we have the different functions called, a different number of times and at different sizes, for the different ARs. Many years ago, Joe and I tried to derive a function to link fpops_est to the AR of the task. We improved on what went before, but it was clear that the curves would have been different for stock apps and optimised apps: for Windows, Linux and OS X: for Intel and AMD. And at that time we were only using CPUs. The approximation is still better than nothing, but it's only ever going to be "good enough", never "absolutely right" - unless you think that BOINC should allow SETI to run benchmark calibrations for every compute device in every host, at every possible AR? I'll leave you to do the math on that one... :-D For AP, fpops_est is the same for every task, but the efficiency (and hence estimate correction) would be different for different degrees of radar blanking. It's much better (and has the opposite sign) since you replaced Josh's algorithm in AP v7, but it's still variable. Maybe the solution for perfect estimates would be to scan the data for radar in the splitter. Any coders willing to offer? ID: 54257 · |
|
Send message Joined: 3 Jan 07 Posts: 1451 Credit: 3,272,268 RAC: 0
|
If it were possible, simply add a DIVIDE by 10 at the end of the current time estimate highlighted above. In my experience that would produce a much more accurate time estimate in both MB & AP. No. A divisor of 10 might be a reasonable figure for the GPUs you personally happen to run, but as you're well aware, the speed range between the slowest and the fastest devices is huge - I'd guess we're up to a factor of 100 or more by now. The main problem is that for those first 10 tasks, there's not even an attempt to incorporate device speed (even theoretical - peak flops times fiddle factor) into the estimation process. And as you point out, when the scheduler is choosing which app_ver to send, and some of them have active APRs and others don't, the answer is ill-defined. Also, in the instance where it is just a version upgrade as with the CPU MB App, simply use the host's existing APR from the current App for the new App. Problem Solved. If the APRs are the same, the Server will most likely send Both tasks instead of the one with the higher APR. Now that is indeed a valid and appropriate solution. In fact, you'll find many posts on this board where Eric has stated that David has told him that this is how it's supposed to work - but it doesn't. For this one particular part of the problem, we need a debugging session, rather than a complete engineering re-write. Mind you, there has to be an operational override tool for this function. I've seen cases where the whole project-wide estimates have been 'poisoned' - usually by the mal-formed deployment of a Beta app in a hurry - and the only way out has been to deploy new app versions with clean estimate tables. ID: 54258 · |
|
Send message Joined: 14 Oct 05 Posts: 1137 Credit: 1,848,733 RAC: 0
|
There is a feature in the app_plan code to bias the early selection of which version to send. Eric tried that for the 7.28 Android apps, the first post in the SETI@home 7.28 for ARM-Android released... thread says: There are two versions. A version that supports NEON, and a "safe" version the just uses VFP instructions. Devices that support NEON could get either, although there should be a 3:1 preference for the neon version. There's reason to believe that feature does not work as intended, but getting David to fix code which doesn't do as designed is often possible. Joe ID: 54259 · |
©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.