urgency: Exactly what you consider it to be. I am providing information, not setting urgency! There'll still be air tomorrow.

BOINC version: 7.6.22 (x64)

OS: Windows 10, up-to-date

processor: AMD A6-4400M APU with Radeon(tm) HD Graphics 2.70 GHz (2 CPUs) No speed demon.

projects: I process mostly SETI@Home, Einstein, and Rosetta for now.

installed as a service: no

condition: Something grabs too many of the CPU cycles in a row; often, I can't interact with the computer for as many as (say) five seconds (inconvenient when editing a document, especially when using the mouse). Much less frequently, I can't interact with the computer for as many as (say) three to five minutes.

my attempts: BOINC Manager >> Options >> Computing Preferences, then (1) Usage limits >> Use at most x% of the CPUs, or (2) Usage limits >> Use at most x% of CPU time, or (3) When to suspend >> Suspend when non-BOINC CPU usage is above x%, or (4) disabling BOINC :( . (That shouldn't be a consideration!), or (5) suspending S@H (Yeah. Not a bit wild about that one, either!)

discussion:
Of the five actions I tried, only disabling BOINC and suspending S@H relieved the sluggishness enough. Then, according to the Task Manager, CPU utilization went way down and my computer was responsive to my inputs. (Duh!) I'm not the smartest person on the planet nor the most knowledgeable person about BOINC, of course, but I think a prime candidate for the condition behind the problem is that all of these controls limit BOINC without considering the other tasks on the computer.

Maybe it'd be nifty if we had a control for "Limit BOINC so that all tasks use at most x% of CPU time". It seems like that'd really use only excess cycles on machines. The user whose interface needs peak at 2% might set this control for 98%. Peak needs of 5%? Set this control for 95%. The machine always feels responsive; BOINC always gets lots of cycles. Happiness.

Back to the smartest person thing: Maybe it's not possible to do; I doubt I'm the first person to have this idea. Or maybe it's entirely a project code thing and all project developers need to relinquish the CPU more frequently than they do (which they don't want).

On the other hand, I think something has changed. I don't remember experiencing this condition in past years.

I posted https://boinc.berkeley.edu/dev/forum_thread.php?id=11118&postid=71031 last night; this is an updated version of that.

While writing that note, I think I had a SETI task running, probably a task that ran on the GPU. At the end of writing that note, I had an Einstein task on the GPU and two Rosetta tasks on the CPUs. I set maximum CPUs, maximum CPU time, and Suspend BOINC when CPU usage is above x (all three settings) to 100% and hoped for the best. Pleasantly, there was no sluggishness.

After I received the two replies on the BOINC board, I set "Suspend BOINC when CPU usage is above" to 85% and decided to watch for changes when S@H next came in.

Einstein's task ended today; I got two SETI tasks (both for the GPU, both with names starting 23oc10aa.1992) to replace it. Sluggishness returned. The first time I noticed it was the longer of the two freeze types, the first SETI task had used only 11 seconds of time (BOINC Manager was frozen on my screen). Apparently, it continued to run during the freeze for me, because when the freeze ended, it updated to near 3 minutes 20 seconds of time. (Presumably the freeze lasted three minutes or a little over.)

I checked through the S@H project settings. The only option I recognized as possibly helping me is to disallow tasks from one of the three projects listed there.

Do you feel that the evidence supports the theory that I have a problem with S@H tasks? Is there something I can do to lessen this sluggishness?

Thanks for reading and for any response. Your work is important to me.

The sluggishness is probably due to the new work units we have from the Breakthrough Listen data.

I'm assuming you are using the advance view of BOINC?

Click on the pulldown under options, click computing preferences

Click on computing, midway on the page is when to suspend

Click on

Suspend GPU computing when computer is in use

This should suspend the work on any projects when you are using the computer

Then under activity,

Make sure it is set to

run based on preferences

and

use GPU based on preferences

Finally go to options and click on

read local pref files


Good luck

It seems to me that you are OVER working your system. REMEMBER that when feeding a GPU; it takes 1 CPU core. With an A6, (I have one), Dual Core APU; this leaves ONLY 1 Core for your system to run other Apps. HOWEVER; you state that you are running Rosetta!!! This will take up one or both of your CPU cores, and thus starve the GPU of MUCH needed CPU cycles.

I recommend dumping Rosetta, or limiting it to one core of the APU.

Otherwise, yes, you can set the "Use at most X CPU" to a higher value limit. I have mine at 50% so that even on my Quad Core Extreme system I'm ONLY using 2 Cores to feed both of my GTX-750TI SC GPUs on the system. I also choose to select "No CPU Use" on BOINC Projects; GUARANTEEING that my 50% level sticks and 2 Cores on my Quad Core Extreme will feed my GPUs and leave me the other two cores for my system use.

On my A6-6400K, these settings guarantee that one CPU core will ALWAYS be free for the system use, and the other core feeds the GTX-760 GPU there.

If you are crunching full tilt on ALL cores of the CPU and trying to crunch GPU AND run your system tasks/apps; it's no wonder why you are experiencing sluggishness.

Scale back some. Dedicate your CPU to feed the GPU ONLY; meaning NO CPU crunching.

My two cents worth.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

Zalster: You said, "The sluggishness is probably due to the new work units we have from the Breakthrough Listen data." I processed a S@H non-Astropulse task last night during which I experienced some sluggishness. I remember its name started with a date (something in the form 10oc15); I see on my Account >> tasks page that task was "SETI@home v8 v8.00". Is that likely from the "Breakthrough Listen data"?



TimeLord04: Good point; I hadn't thought of tradeofs between the GPU and CPU. Since the GPU is so much faster, if a task (like an S@H/AstroPulse task I'm running now) says it needs 0.56 CPU with the GPU, a system with a fully engaged GPU and a sometime-idling CPU could well produce more than a system with a sometime-idle GPU that's chasing the "wasted" 0.44 CPU. I processed another S@H task last night that said in needed only 0.0333 CPU; maybe that one can afford chasing the remaining 0.9667 CPU. I'll presume that you base your advice on experimentation and observation of the typical mix of CPU needs for GPU tasks.

I set my BOINC preferences to "Use at most 99% of the CPUs", thinking 50% of the CPUs (1 CPU) would get a CPU-only task, and 49% of CPUs (98% of the remaining CPU) would seldom allow the CPU paired with the GPU to constrain the GPU.

My task manager isn't reporting anything near 0.56 CPU for the Astropulse task. In the highest I've seen, it used less than 8% of capacity (so, less than 16% of the one CPU), but maybe it'll spike up in another part of the task. My system is often using less than 70% of total CPU, so there's plenty to spare.

Thanks for making the point. If sluggishness returns, I might look for other options. This seems a step in the right direction.

Hello Garry,

You can tell most breakthrough listen data as it starts with blc in the name

You can't really tell how much CPU is being used from the BOINC manager.

If you are interested in finding out how much CPU you are actually using, I would suggest getting boinc tasks

http://efmer.com/b/?q=boinctasks_download

This will show you how much of a CPU each work unit actually uses rather than the value boinc Manager says it should use.

Zalster,

Thanks for the pointer to BOINC Tasks. It seems like BOINC Manager with some good bells and whistles. I have it running.

I have my computer configured to run only two tasks at a time, one CPU-only and one GPU.

Now that I'm looking, it appears that the sluggishness occurs only while S&H tasks run and not only on those starting with blc. The constraint causing the lockouts does not appear to be the processor; Task Manager reports CPU usage as variable, but mostly in the range of 60 to 80%. And, when I allowed BOINC access to only one of my two CPUs, I still got the lockouts. Perhaps two or three times a minute, I get lockouts lasting a second or two; perhaps twice a day, I get one that's three or four minutes. This longer one is not tied to the end of a S@H task.

The lockouts are inconvenient, but not so bad that I'm blocking tasks from S&H (yet).

It'd be great for the S@H programmers to check their code looking for relevant differences between their code and that of other projects. Further reduction of these lockouts would be welcome.

---

Garry,

If the lockout occur when only running Seti@home then it might be worth looking at adding a simple commandline like -use_sleep to decrease CPU usage to free it for your computer.

That is much more complicated item to do.

First question

Do you know where you seti@home fold is located?

And if so have you ever had to access it.

Next do you know how to make an xml file?

That is enough to start with. I'll await your response if you want to go this route.

@Garry

Direct from the project:  Message 1778453

If the lockout occur when only running Seti@home then it might be worth looking at adding a simple commandline like -use_sleep to decrease CPU usage to free it for your computer.

Zalster,

I'm not going to muddle the thread by barging into your trouble-shooting flowchart, but I suggest you possibly need to establish which of the many possible setiathome applications is implicated in the lockouts: not all of them accept -use_sleep as a parameter (and I don't think it applies to any of those targeted at a Radeon APU). Since Garry's comupter is hidden, I can't tell which apps might actually be in use.

Hi Richard,

It's fine, any thoughts you might have are welcome.

Since it's the first of the month, I will probably take time to get back to this thread so go ahead and if you can think of anything that will help him

Zalster

If the lockout occur when only running Seti@home then it might be worth looking at adding a simple commandline like -use_sleep to decrease CPU usage to free it for your computer.

Zalster,

I'm not going to muddle the thread by barging into your trouble-shooting flowchart, but I suggest you possibly need to establish which of the many possible setiathome applications is implicated in the lockouts: not all of them accept -use_sleep as a parameter (and I don't think it applies to any of those targeted at a Radeon APU). Since Garry's comupter is hidden, I can't tell which apps might actually be in use.

-use_sleep is available for APU`s but i rather think -period_iterations_num could help in this case.
But with his host hidden its hard to tell.

---

With each crime and every kindness we birth our future.

In all cases of GUI sluggishness with OpenCL app please recommend to use r3500 apps as preferable ways (if OP able going to Anonymous platform of course).
After some alfa testing r3500 will be RC and go to beta.

---

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

Wow! Thanks for all the activity!

Answering Zalster's questions: I'm comfortable working with XML and the S@H folder.

Taking the hint from others: My computer is now visible. I regret any inconvenience.

The tasks that have been problematic include the blc... tasks. And at least one more group; I didn't catch the name. I completed one such task earlier today.

I've been working through a task tonight starting 20fe09af... It has not been a problem.