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

To post messages, you must log in.

1 · 2 · 3 · 4 . . . 15 · Next

AuthorMessage
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 54204 - Posted: 20 May 2015, 8:56:42 UTC

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 · Report as offensive
Urs Echternacht
Volunteer tester
Avatar

Send message
Joined: 18 Jan 06
Posts: 1038
Credit: 18,734,730
RAC: 0
Germany
Message 54205 - Posted: 20 May 2015, 15:14:24 UTC

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 · Report as offensive
Profile David S
Volunteer tester
Avatar

Send message
Joined: 10 Sep 13
Posts: 1187
Credit: 2,791,413
RAC: 48
United States
Message 54209 - Posted: 20 May 2015, 20:46:31 UTC - in response to Message 54204.  

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.

I'll turn loose my i7 on it.
David
signature sent back to alpha testing
ID: 54209 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54222 - Posted: 22 May 2015, 0:55:23 UTC - in response to Message 54205.  

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
Thu 21 May 2015 07:59:06 PM EDT | | OpenCL: AMD/ATI GPU 0: Juniper (driver version 1642.5, device version OpenCL 1.2 AMD-APP (1642.5), 1024MB, 1024MB available, 720 GFLOPS peak)
Thu 21 May 2015 07:59:06 PM EDT | | OpenCL: AMD/ATI GPU 1: Cayman (driver version 1642.5 (VM), device version OpenCL 1.2 AMD-APP (1642.5), 1986MB, 1986MB available, 1690 GFLOPS peak)
Thu 21 May 2015 07:59:06 PM EDT | | OpenCL CPU: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz (OpenCL driver vendor: Advanced Micro Devices, Inc., driver version 1642.5 (sse2), device version OpenCL 1.2 AMD-APP (1642.5))
Thu 21 May 2015 07:59:06 PM EDT | | OS: Linux: 3.8.0-44-generic
Thu 21 May 2015 07:59:06 PM EDT | | Computer location: work
Thu 21 May 2015 08:05:30 PM EDT | SETI@home Beta Test | [sched_op] Starting scheduler request
Thu 21 May 2015 08:05:30 PM EDT | SETI@home Beta Test | Sending scheduler request: To fetch work.
Thu 21 May 2015 08:05:30 PM EDT | SETI@home Beta Test | Requesting new tasks for ATI
Thu 21 May 2015 08:05:30 PM EDT | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
Thu 21 May 2015 08:05:30 PM EDT | SETI@home Beta Test | [sched_op] ATI work request: 53235.52 seconds; 2.00 devices
Thu 21 May 2015 08:05:31 PM EDT | SETI@home Beta Test | Scheduler request completed: got 0 new tasks
Thu 21 May 2015 08:47:23 PM EDT | SETI@home Beta Test | [sched_op] Starting scheduler request
Thu 21 May 2015 08:47:23 PM EDT | SETI@home Beta Test | Sending scheduler request: To fetch work.
Thu 21 May 2015 08:47:23 PM EDT | SETI@home Beta Test | Requesting new tasks for ATI
Thu 21 May 2015 08:47:23 PM EDT | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
Thu 21 May 2015 08:47:23 PM EDT | SETI@home Beta Test | [sched_op] ATI work request: 35995.83 seconds; 2.00 devices
Thu 21 May 2015 08:47:24 PM EDT | SETI@home Beta Test | Scheduler request completed: got 0 new tasks
ID: 54222 · Report as offensive
Urs Echternacht
Volunteer tester
Avatar

Send message
Joined: 18 Jan 06
Posts: 1038
Credit: 18,734,730
RAC: 0
Germany
Message 54224 - Posted: 22 May 2015, 11:18:35 UTC

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 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 54226 - Posted: 22 May 2015, 17:45:00 UTC

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 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54230 - Posted: 22 May 2015, 20:23:54 UTC - in response to Message 54226.  

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 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54240 - Posted: 23 May 2015, 17:12:50 UTC
Last modified: 23 May 2015, 17:16:51 UTC

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.
Sat 23 May 2015 01:13:28 PM EDT | SETI@home Beta Test | Requesting new tasks for ATI
Sat 23 May 2015 01:13:28 PM EDT | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
Sat 23 May 2015 01:13:28 PM EDT | SETI@home Beta Test | [sched_op] ATI work request: 261054.33 seconds; 2.00 devices
Sat 23 May 2015 01:13:29 PM EDT | SETI@home Beta Test | Scheduler request completed: got 0 new tasks
Sat 23 May 2015 01:13:39 PM EDT | SETI@home Beta Test | Sending scheduler request: To fetch work.
Sat 23 May 2015 01:13:39 PM EDT | SETI@home Beta Test | Requesting new tasks for ATI
Sat 23 May 2015 01:13:39 PM EDT | SETI@home Beta Test | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
Sat 23 May 2015 01:13:39 PM EDT | SETI@home Beta Test | [sched_op] ATI work request: 261075.67 seconds; 2.00 devices
Sat 23 May 2015 01:13:40 PM EDT | SETI@home Beta Test | Scheduler request completed: got 0 new tasks


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 · Report as offensive
Urs Echternacht
Volunteer tester
Avatar

Send message
Joined: 18 Jan 06
Posts: 1038
Credit: 18,734,730
RAC: 0
Germany
Message 54244 - Posted: 23 May 2015, 23:27:46 UTC

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 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54246 - Posted: 24 May 2015, 0:57:33 UTC - in response to Message 54244.  

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 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 54248 - Posted: 24 May 2015, 7:32:05 UTC - in response to Message 54246.  

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 · Report as offensive
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1451
Credit: 3,272,268
RAC: 1
United Kingdom
Message 54249 - Posted: 24 May 2015, 11:07:13 UTC

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 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 54250 - Posted: 24 May 2015, 13:36:26 UTC - in response to Message 54249.  

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 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54251 - Posted: 24 May 2015, 20:49:49 UTC - in response to Message 54248.  

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.

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 · Report as offensive
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1451
Credit: 3,272,268
RAC: 1
United Kingdom
Message 54252 - Posted: 24 May 2015, 22:48:37 UTC - in response to Message 54251.  

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 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 54253 - Posted: 24 May 2015, 23:25:56 UTC - in response to Message 54252.  
Last modified: 24 May 2015, 23:30:02 UTC


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.

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 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 2 Jul 13
Posts: 505
Credit: 5,019,318
RAC: 0
United States
Message 54255 - Posted: 24 May 2015, 23:47:47 UTC - in response to Message 54252.  

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.

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 · Report as offensive
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1451
Credit: 3,272,268
RAC: 1
United Kingdom
Message 54257 - Posted: 25 May 2015, 7:42:24 UTC - in response to Message 54253.  

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.
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.

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 · Report as offensive
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1451
Credit: 3,272,268
RAC: 1
United Kingdom
Message 54258 - Posted: 25 May 2015, 7:58:41 UTC - in response to Message 54255.  

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.
That wasn't too difficult, was it.

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 · Report as offensive
Josef W. Segur
Volunteer tester

Send message
Joined: 14 Oct 05
Posts: 1137
Credit: 1,848,733
RAC: 0
United States
Message 54259 - Posted: 25 May 2015, 17:09:08 UTC

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 · Report as offensive
1 · 2 · 3 · 4 . . . 15 · Next

Message boards : SETI@home Enhanced : OpenCL MultiBeam for Windows, Linux and OS X updated. Please test thoroughly.


 
©2020 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.