The best fix for the AMD GPUs is running on Beta right now, and appears to be doing well, http://setiweb.ssl.berkeley.edu/beta/setiathome_v8_x86_64-apple-darwin__opencl_ati5_mac.html
The question is how long will it take to move it to Main.

Who can give warranty that same issue will not appear after deployment on main? Cause prev deployment was under same conditions - "stable" binary from beta...
I'll not recommend any promote until the reason of currrent failure will be found. With binary we already deployed.

Since 8.22r3610 has been the current version for most of a Year, there are a few other people that have been running it on Main for quite some time without getting any of these Too Many Exits errors. That may not "give warranty that same issue will not appear" on the version loaded onto the SETI Server, however, it would give rise to a whole new set of questions if the same App run under Anonymous platform doesn't produce that error and the App on the SETI Server did. It might 'cut to the chase' so to speak and save weeks or even months of needless conjecture. Right now, v8.22r3610 is working on SETI Main, I see absolutely no reason for it not to continue working...unless there is some problem with the SETI Server.

BTW, this is how long people have been running r3610 on Main without getting those errors,

Message 1845237 - Posted: 29 Jan 2017, 20:34:46 UTC
I replaced the Old ATi5r3552 with the new package ATi5r3610&CPU-AVX.zip...

Why on Earth would you use the Baseline 75 App when you can use the Much faster Special 75 App with your Maxwell cards? I dunno, I suppose it might make sense to someone.

It's simple as cube: Because it doesn't pass testing still. We have special thread on it on main. And current state of that thread self-telling, there are few identified issues that pending for Petri's fixes.
On other side, I would vote for promotion Petri's app for formal beta testing on SETI servers if he would not disallow this. On beta we can see result stderrs much longer at least so this simplifies testing and bug-tracking. And we could start with yours binaries for Mac of Petri's app. If no objections I would write Eric about that (as usual I need direct links to binaries you wanna put on beta). Regarding deployment on main - not yet.
If Petri's app will go on beta servers CUDA75 baseling could be removed from them at the same time (and this will simplify maintenance for Eric also).
So, lets think if we can vote for such changes.

I see such apps currently on beta servers:
Mac OS X/64-bit Intel 8.10 (opencl_nvidia_SoG_mac) 7 Apr 2016, 1:01:54 UTC 0 GigaFLOPS
Mac OS X/64-bit Intel 8.11 (cuda42_mac) 6 Aug 2016, 4:12:08 UTC 0 GigaFLOPS
Mac OS X/64-bit Intel 8.11 (cuda75_mac) 6 Aug 2016, 4:12:08 UTC 0 GigaFLOPS
Mac OS X/64-bit Intel 8.19 (opencl_nvidia_mac) 8 Nov 2016, 23:03:25 UTC 21 GigaFLOPS

Numbers are quite interesting. They tell that the single app we really TEST currently is 8.19 (opencl_nvidia_mac) 8 Nov 2016, 23:03:25 UTC.
Do we deployed this binary on main already? Your post about CUDA42 and CUDA75 but single app that does processing on beta is OpenCL one it seems instead!

---

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

Since 8.22r3610 has been the current version for most of a Year, there are a few other people that have been running it on Main for quite some time without getting any of these Too Many Exits errors. That may not "give warranty that same issue will not appear" on the version loaded onto the SETI Server, however, it would give rise to a whole new set of questions if the same App run under Anonymous platform doesn't produce that error and the App on the SETI Server did. It might 'cut to the chase' so to speak and save weeks or even months of needless conjecture. Right now, v8.22r3610 is working on SETI Main, I see absolutely no reason for it not to continue working...unless there is some problem with the SETI Server.

Absolutely the same could be written about recently deployed binary that DOES make errors after deployment.

Try to replace r3610 on main with current ATi "stock" binary on main. And see if it will start to produce those errors on your host (same host that works OK with r3610 as anonymous platform). If "stock" being run as anonymous platform will produce same errors on main - that's sign we really need to replace binary with new revision again.

---

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

...Numbers are quite interesting. They tell that the single app we really TEST currently is 8.19 (opencl_nvidia_mac) 8 Nov 2016, 23:03:25 UTC.
Do we deployed this binary on main already? Your post about CUDA42 and CUDA75 but single app that does processing on beta is OpenCL one it seems instead!

Back here Raistmer, https://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2266&postid=61423#61423

I would recommend the 8.11 (cuda75_mac) Baseline App be removed from Main and Beta and the 8.11 (cuda42_mac) plan class allow the App to work on all nVidia GPUs.

This link is on Main, Horrible Results Wasting Resources on MAIN

Apps on Main, https://setiathome.berkeley.edu/apps.php;
Mac OS X/64-bit Intel : 8.11 (cuda42_mac) : 16 Nov 2016, 1:55:03 UTC : 112 GigaFLOPS
Mac OS X/64-bit Intel : 8.11 (cuda75_mac) : 16 Nov 2016, 1:55:03 UTC : 242 GigaFLOPS
Mac OS X/64-bit Intel : 8.19 (opencl_nvidia_mac) : 28 Dec 2016, 23:34:07 UTC : 9,444 GigaFLOPS

Since 8.22r3610 has been the current version for most of a Year, there are a few other people that have been running it on Main for quite some time without getting any of these Too Many Exits errors. That may not "give warranty that same issue will not appear" on the version loaded onto the SETI Server, however, it would give rise to a whole new set of questions if the same App run under Anonymous platform doesn't produce that error and the App on the SETI Server did. It might 'cut to the chase' so to speak and save weeks or even months of needless conjecture. Right now, v8.22r3610 is working on SETI Main, I see absolutely no reason for it not to continue working...unless there is some problem with the SETI Server.

Absolutely the same could be written about recently deployed binary that DOES make errors after deployment.

Try to replace r3610 on main with current ATi "stock" binary on main. And see if it will start to produce those errors on your host (same host that works OK with r3610 as anonymous platform). If "stock" being run as anonymous platform will produce same errors on main - that's sign we really need to replace binary with new revision again.

Can you give me a link to some Mac running 8.20r3552 (opencl_ati5_mac) under Anonymous platform on Main? I don't know of Any running r3552 under Anonymous platform. That App was replaced Long ago by 8.22r3610, I do know of a few running 8.22r3610 on Main under Anonymous platform. So NO, the same could NOT be written about recently deployed binary. As noted previously, the ATI Series 5 cards aren't showing this Error, and I don't see any ATI Series 6 cards showing this Error either, I have ATI Series 6 cards and I've Never seen this Error. The Error seems to start with the Series 7 cards.

Good Luck trying to get someone with a Series 7 or higher card to run 8.20r3552 on Main under Anonymous platform. There are already people running 8.22r3610 on Main under Anonymous platform.
Can you give me One reasonable reason Not to update to 8.22r3610 on Main?

This link is on Main, Horrible Results Wasting Resources on MAIN

Ouch, look at the stderr for some of those: page after page of

Cuda error 'find_triplets_kernel' in file 'cuda/cudaAcc_pulsefind.cu' in line 264 : too many resources requested for launch.

Who the hell let that one out of the hutch?

Back when that CUDA 75 App was built We didn't know the older GPUs didn't work well with anything above CUDA 6.0. That 4000 card is a Fermi card, I've also seen bad results from 780s running that App. Most of the Mac nVidia GPUs at Beta are Keplers in iMacs and it worked fairly well in those machines. The Baseline CUDA 75 App works fine in Maxwells and Pascals as seen in the below Benchmark, just don't run it on a Fermi. The App needs to be removed or at least tagged for Maxwells and above, I vote for removal as people may confuse it with the CUDA 75 Special App which also runs on Maxwells.

Back when that CUDA 75 App was built We didn't know the older GPUs didn't work well with anything above CUDA 6.0. That 4000 card is a Fermi card, I've also seen bad results from 780s running that App. Most of the Mac nVidia GPUs at Beta are Keplers in iMacs and it worked fairly well in those machines. The Baseline CUDA 75 App works fine in Maxwells and Pascals as seen in the below Benchmark, just don't run it on a Fermi. The App needs to be removed or at least tagged for Maxwells and above, I vote for removal as people may confuse it with the CUDA 75 Special App which also runs on Maxwells.

The best way to help Eric tag the app appropriately for NVidia cards is to give him the minimum 'compute capability' for usable cards - that's detected by BOINC, and can be filtered by the plan_class definition. Chip codenames don't help unless you expect him to wade through the whole of List of Nvidia graphics processing units.

Here's a shorter list checked from my own machines.

Card		Comp. Cap.	Codename
GTX 470		2.0		Fermi
GTX 670		3.0		Kepler
GTX 750Ti	5.0		Maxwell
GTX 970		5.2		Maxwell

Of course, you'll still get errors if someone has loaded a 'bad' card and a 'good' card in the same machine, set 'use all GPUs', and not excluded the 'bad' card from this application or project.

I added a compute capability >= 3.0 to the plan class.

---

I added a compute capability >= 3.0 to the plan class.

Thanks, but unfortunately I don't think it's worked. That "Horrible Results Wasting Resources on MAIN" link was to host 7823473, which has a single NVIDIA Quadro 4000. Not one we often come across, but that huge Wiki comparison says it has a GF100 core chip inside: the 'F' in that name is an indicator that it's from the Fermi generation. Unfortunately the compute capability isn't listed directly.

But the computer is still being allocated SETI@home v8 v8.11 (cuda75_mac) tasks - most recently 15 minutes ago - so the filter hasn't taken yet. Maybe with the restart after maintenance? I'll look again tomorrow.

Nope - it's still getting them.

Can you give me One reasonable reason Not to update to 8.22r3610 on Main?

Yes. Last update was unsuccessful for still unknown reason.

---

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

Since 8.22r3610 has been the current version for most of a Year, there are a few other people that have been running it on Main for quite some time without getting any of these Too Many Exits errors. That may not "give warranty that same issue will not appear" on the version loaded onto the SETI Server, however, it would give rise to a whole new set of questions if the same App run under Anonymous platform doesn't produce that error and the App on the SETI Server did. It might 'cut to the chase' so to speak and save weeks or even months of needless conjecture. Right now, v8.22r3610 is working on SETI Main, I see absolutely no reason for it not to continue working...unless there is some problem with the SETI Server.

Absolutely the same could be written about recently deployed binary that DOES make errors after deployment.

Try to replace r3610 on main with current ATi "stock" binary on main. And see if it will start to produce those errors on your host (same host that works OK with r3610 as anonymous platform). If "stock" being run as anonymous platform will produce same errors on main - that's sign we really need to replace binary with new revision again.

Can you give me a link to some Mac running 8.20r3552 (opencl_ati5_mac) under Anonymous platform on Main? I don't know of Any running r3552 under Anonymous platform. That App was replaced Long ago by 8.22r3610, I do know of a few running 8.22r3610 on Main under Anonymous platform. So NO, the same could NOT be written about recently deployed binary. As noted previously, the ATI Series 5 cards aren't showing this Error, and I don't see any ATI Series 6 cards showing this Error either, I have ATI Series 6 cards and I've Never seen this Error. The Error seems to start with the Series 7 cards.

Good Luck trying to get someone with a Series 7 or higher card to run 8.20r3552 on Main under Anonymous platform. There are already people running 8.22r3610 on Main under Anonymous platform.
Can you give me One reasonable reason Not to update to 8.22r3610 on Main?

Unfortunately you don't mke any attempt to make following of that completely alien proprietary world of Macs for me.
So, perhaps better will be to leave this to one who can follow your descriptions.
I implied you can test those 2 revs on own hardware. Perhaps - not.

---

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

Unfortunately you don't mke any attempt to make following of that completely alien proprietary world of Macs for me.
So, perhaps better will be to leave this to one who can follow your descriptions.
I implied you can test those 2 revs on own hardware. Perhaps - not.

I tested those old Apps a year ago when I built them. Not quite a year on 3610, yet, they worked perfectly fine on My machine and on this one as well, https://setiathome.berkeley.edu/forum_thread.php?id=80359&postid=1845663#1845663. No One has reported a problem with 8.22r3610. I have 6800 GPUs, My GPUs apparently don't have the problem being seen on Main, neither do the 5000 series. There are Newer GPUs running r3610 on Main as we speak, None of them are having that problem. I don't see why you won't accept that.

Meanwhile, I've managed to build a new version 3710, which might be even better than 3610. It seems to be giving good results and the Idle Wakeup numbers are even lower than with 3610. I'll be testing 3710, there isn't any reason for me to ReTest something I've already tested on hardware that doesn't seem to have the Error anyway.
Oh, I also have a couple of other new openCL Apps...that seem to work well on my nVidia cards.

Here's another Mac with a Non-Apple GPU getting the -226 (0xFFFFFF1E) ERR_TOO_MANY_EXITS Error with 8.19r3551 opencl_nvidia_mac App. As I said previously, I've seen Macs with Non-Apple supplied nVidia GPUs and Hackintoshs receive this Error with r3551 opencl_nvidia_mac.
<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
too many boinc_temporary_exit()s
</message>
Application version : SETI@home v8 v8.19 (opencl_nvidia_mac) x86_64-apple-darwin
I know, it's not supposed to matter if the App just happens to be from the EXACT same code as 8.20r3552...just a coincidence. Just a coincidence I keep seeing Non-Apple nVidia GPUs and Hackintoshes get this Error with the nVidia App, which is really an Intel iGPU App. Hmmm, I think that's the same 780 I saw trashing a number of CUDA 75 tasks a while back. BTW, this Fermi GPU is still being sent CUDA 75 tasks, https://setiathome.berkeley.edu/results.php?hostid=7823473. Strange how the server has never once sent that Host the CUDA 42 App.

The New Apps based on 3710 seem to be running well, I suppose I should post them at C.A. at some point. The biggest improvement is with the r3711 SSE41 CPU App, it's around 15% faster than the old r3344 App. The other two aren't much different than the existing Apps. I have no idea if anyone will get the TOO_MANY_EXITS Error with them, I've Never received that Error, and I've run many, many different Apps.

Look, here's another Non-Apple GPU;
<core_client_version>7.6.33</core_client_version>
<![CDATA[
<message>
too many boinc_temporary_exit()s
</message>
SETI@home v8 v8.19 (opencl_nvidia_mac) x86_64-apple-darwin
At least the iGPU version is leaving a message in the <stderr_txt>.

I tested those old Apps a year ago when I built them. Not quite a year on 3610, yet, they worked perfectly fine on My machine and on this one as well, https://setiathome.berkeley.edu/forum_thread.php?id=80359&postid=1845663#1845663. No One has reported a problem with 8.22r3610. I have 6800 GPUs, My GPUs apparently don't have the problem being seen on Main, neither do the 5000 series. There are Newer GPUs running r3610 on Main as we speak, None of them are having that problem. I don't see why you won't accept that.

Sadly, it doesn't work that way.

If you want to build your own app to run on your own machine, you're welcome - be my guest. That's exactly what open source development makes possible. And if you wish to invite a few friends to test your private build, I don't see anything wrong with that, either.

But the bar is set higher when you expect the University of California to take responsibility for publishing your work, by making it available for download as a stock application, anywhere in the world. You really should make every effort to test it on as many variants as possible of the target hardware (computer systems and, in this case, GPU models), and as many variants as possible of the target software (operating system and BOINC versions). Ideally, a stock release under the UCL banner should be universal - self-adjusting to all variants of both hardware and software: but if it is built for a subset only (perhaps "post- Fermi", as we were discussing the other day), that needs to be made clear in technical terms when you offer the app to Eric for deployment.

I tested those old Apps a year ago when I built them. Not quite a year on 3610, yet, they worked perfectly fine on My machine and on this one as well, https://setiathome.berkeley.edu/forum_thread.php?id=80359&postid=1845663#1845663. No One has reported a problem with 8.22r3610. I have 6800 GPUs, My GPUs apparently don't have the problem being seen on Main, neither do the 5000 series. There are Newer GPUs running r3610 on Main as we speak, None of them are having that problem. I don't see why you won't accept that.

Sadly, it doesn't work that way.

If you want to build your own app to run on your own machine, you're welcome - be my guest. That's exactly what open source development makes possible. And if you wish to invite a few friends to test your private build, I don't see anything wrong with that, either.

But the bar is set higher when you expect the University of California to take responsibility for publishing your work, by making it available for download as a stock application, anywhere in the world. You really should make every effort to test it on as many variants as possible of the target hardware (computer systems and, in this case, GPU models), and as many variants as possible of the target software (operating system and BOINC versions). Ideally, a stock release under the UCL banner should be universal - self-adjusting to all variants of both hardware and software: but if it is built for a subset only (perhaps "post- Fermi", as we were discussing the other day), that needs to be made clear in technical terms when you offer the app to Eric for deployment.

You need to clarify that a little there Richard. It sounds as thought you are saying since I have a limited number of different GPUs I'm SOL. This is the same ATI GPU I have, as you can see, that GPU, the same one as mine, isn't receiving any Error with 8.20r3552. Back when I tested it over a year ago, I didn't receive any Errors either, https://setiathome.berkeley.edu/results.php?hostid=7492917. In fact, I haven't found a Single 5000 or 6000 series ATI card anywhere on SETI having the Too Many Exits Error. Right now I'm testing 8.22r3710 because, I'm the only one that has it. I've Already tested r3552 over a Year ago, r3610 almost a Year ago, now I'm on to current releases. Just what are you trying to tell me? I should stop any further testing and go back to testing something I did over a year ago that many other people have? I just created a new group of Apps based on the lasted code, I should just forget about them and go back to testing something hundreds of others are testing? Sorry, this makes absolutely No Sense to me. Maybe I should just go back to working on the cuda app, it's what I use anyway.

I'm still waiting on a little clarification. I believe most of use around here thought the purpose of SETI Beta was to, "really should make every effort to test it on as many variants as possible of the target hardware (computer systems and, in this case, GPU models), and as many variants as possible of the target software (operating system and BOINC versions). ."

Sadly, it doesn't work that way.

If you want to build your own app to run on your own machine, you're welcome - be my guest. That's exactly what open source development makes possible. And if you wish to invite a few friends to test your private build, I don't see anything wrong with that, either.

But the bar is set higher when you expect the University of California to take responsibility for publishing your work, by making it available for download as a stock application, anywhere in the world. You really should make every effort to test it on as many variants as possible of the target hardware (computer systems and, in this case, GPU models), and as many variants as possible of the target software (operating system and BOINC versions). Ideally, a stock release under the UCL banner should be universal - self-adjusting to all variants of both hardware and software: but if it is built for a subset only (perhaps "post- Fermi", as we were discussing the other day), that needs to be made clear in technical terms when you offer the app to Eric for deployment.

I'm also at a loss to understand why you refer to this as 'your work'. My name doesn't appear anywhere in the software, which can be found here, https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt, I'm sure most know whose software it is. I'm really not expecting anything from the University of California, I merely posted software from their site in case others find it useful. If the University of California finds it useful, they are welcome to use the software from their site, I expect nothing.
1) The ATI App passed the University of California's Beta testing, apparently they found it worked well enough for their needs. I only have One Mac, with One type of ATI GPU, the App works on my machine.
2) The CUDA 75 App passed the University of California's Beta testing, apparently they found it worked well enough for their needs. I don't have a Fermi or Kepler GPU, it's impossible for me to know how the University of California's software will work with hardware I don't have. Again, Most of us thought that was the purpose of SETI Beta.
What is the purpose of SETI Beta? If you are expecting Volunteers with limited resources to do the complete Beta testing for the University of California please remove any software you consider "mine" from the University of California, I have no interest in what you apparently expect from this Volunteer.

Let's wait until Eric has finished firefighting a failing server at SETI Main - that comes first in the priority list.

Then I'd like to have a proper discussion with both you and Eric about what is expected before an application is accepted for deployment as a stock application on that SETI Main server, what the procedure should be if problems are spotted after deployment, and what threshhold of 'problem rate' we would all regard as acceptable.

Well, we definitely have 2 issues here:
1) Lack of adequate testing tasks on beta.
2) Lack of direct communication between OS X apps builder/tester (at least partial tester) and Eric.

All last OS X binaries updates passed through my understanding of OS X current situation (having no Mac hardware and no even slightest desire to have it) .
Maybe would be better if more direct route will be functional.

What demands from TBar as binaries reliser are valids from my point of view is to be as descriptive as possible regarding what hardware and what software/OS involved. Personally I'm lost in all those Maverics and whatever (ut seems Google tries to be next Apple on all terms, including proprietary APIs and non-consistent naming schemes). What plan class sees is OS version number, not all those fancy PR names. W/o clear vision for what subset of hosts some binary intended plan_class creation not possible. Maybe some help if other volunteers from Mac-side of world required here.

---

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