ok.. thanks for the help..

---

ok.. thanks for the help..

No probs. We lose ~2 days though in initial phase. Eric was not aware of app's way to check for exit and I was not aware about this thread :)

Will return back if some another flag should be checked, stay subscribed on this thread.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

will do...

---

Did not get any definite response from BOINC devs still, but lets try some "workaround". There is another flag that name points to it relevance.
I will add it to monitored ones. Maybe this will fix issue.
Await new build shortly.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Here is the new build that maybe has workaround for suspending issue: https://dl.dropboxusercontent.com/u/60381958/MB7_win_x86_SSE_OpenCL_ATi_HD5_r1840.7z

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

no luck with that either...

---

no luck with that either...

Ok, here is even another one.
What you could get with this new build: maybe app will not exit (process will remain in task manager list), but it will consume almost no CPU and GPU. Please check if it's the case or app still making progress and uses CPU/GPU resources when it should not.

https://dl.dropboxusercontent.com/u/60381958/MB7_win_x86_SSE_OpenCL_ATi_HD5_r1843.7z

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Awesome does as you said.. I think once it quit properly all the other times I tested it stopped processing but stayed in memory...

---

Awesome does as you said.. I think once it quit properly all the other times I tested it stopped processing but stayed in memory...

Just as I feared... I fixed another one issue with suspending - app did not stop while BOINC did benchmark. It leaves app in memory while doing this. So the fix was "to stop execution but do not exit".
That's what app does. But in your case full exit is more desired indeed.
Unfortunately, there is no known for me way to distinguish between BOINC suspend commands for those 2 cases. I believe that in your case BOINC behaves wrong though. It should set quit request flag but doesn't. It set only suspend flag and app obeys.
I think in such semi-suspended way it should interfere with your daily work much less anyway. if not worth to rise this issue on BOINC forums again.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

In the end it was a BOINC API problem; It does require that new science applications be built.

API: fix bug involving suspend and critical sections.

Old: if the timer thread gets a <suspend> message while we're in a critical section, it sets a "suspend_request" flag.
The timer then periodically (10X/sec) checks whether suspend_request is set and we're no longer in a critical section; if so it suspends the worker thread.

Problem (pointed out by Oliver Bock): this doesn't work if the worker thread is almost always in a critical section (as is the case for GPU apps, which treat GPU kernels as critical sections). The app never gets suspended.

New:
1) boinc_end_critical_section() checks suspend_request; if set, it calls suspend_activities()
2) On Unix, if suspend_activities() is called from the worker thread, it calls sleep() in a loop until the suspension is over. (Note: pthreads has no suspend/resume).
3) Add a mutex to protect the data structures shared between the timer and worker threads.

---

thanks for the update... its good to hear something has happened...
interestingly sometimes my GPU apps exit correctly.. so I guess the info sometimes gets through...

---

In the end it was a BOINC API problem; It does require that new science applications be built.

So now is it fixed or not? I downloaded the Boinc client just a few days ago and have this problem. The previous version didn't have it. The previous post has files for ATI (and I have Nvidia).

---

In the end it was a BOINC API problem; It does require that new science applications be built.

So now is it fixed or not? I downloaded the Boinc client just a few days ago and have this problem. The previous version didn't have it. The previous post has files for ATI (and I have Nvidia).

AFAIK, the problem in this thread involves ATI cards only, not NVIDIA. From your task list, I can see you're trashing v7 GPU units with a 226 error (too many exits). I would think this is a totally different situation. For one thing, your NVIDIA driver is really old, but then, the 9500 is an older card. You might want to update the driver first, and see if that corrects the errors. I am not familiar enough with the 226 error to offer any ideas about it otherwise.

---

Boinc manager is 7.0.64, the newest.
Don't know how to update astropulse (it should do it automatically).
Astropulse says Opencl_Nvidia_100 version.
Boinc manager says Setiathome and Astropulse are suspended because cpu is in use, but still 50% cpu time. Though not always..

---

Oh, thanks, didn't notice the ATI at the top of thread :)
So maybe I could try shutting down the GPU totally in the BOINC.
Except I probably should find a non-gpu using version of Astropulse
and don't yet know how to do that...
(Though still don't understand why it should behave like this)

---

It should not. It's bug in BOINC API (damaging NV OpenCL app just as OpenCL Ati app). To fix this bug 1) API should be corrected (not sure if it's the case already)
2) new BOINC libs should be generated
3) SETI apps should be re-linked vs this new libraries.

I'm inclined to do 2) and 3) only after being sure 1) is really done. Awaiting reports from Einstein OpenCL team.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.