Is your ressource share high enough, say >30% than the combined share for all cpu projects?

MrS

---

Scanning for our furry friends since Jan 2002

Yes ETA it is 5-10 times higher than any individual project and over 30% higher than the total ....but I will crank it up even more....good idea

For info: I tried experimenting by setting cpu_sched=0 in the cc_config file.

It appears to have stopped boinc pre-empting the GPU task for now and, as yet, I see no other unwanted behaviour.

These two Linux boxes are running 1 CPU project (2 tasks) plus GPU grid, both projects at 50% resource share They run with 6.3.10, and ncpus=2.

---

Nightlord could you layout the cc_config file the way you have it setup so that I may copy and paste it please?

This is my cc_config.xml file:

<cc_config>
    <log_flags>
	<task>1</task>
	<cpu_sched>0</cpu_sched>
    </log_flags>
    <options>
	<ncpus>2</ncpus>
        <report_results_immediately>1</report_results_immediately> 
    </options>
</cc_config>

I think there are dangers in adjusting the cpu scheduler setting, but it seems to be ok for one CPU project plus GPU....be careful if you run more than one CPU project.

YMMV

edit: it last lost some formatting by posting to the forum, so you may need to adjust the tabbed spacing in your file.

---

Ok thanks its appreciated...I will adjust it as I am running this on a quad and will watch for strange behaviour...

I don't see why a log flag should change the behaviour of the scheduler, but who knows... ;)

---

pixelicious.at - my little photoblog

Nope ....good try Nightlord but did not work....on bootup runs 20-30 secs and still goes to waiting.

Checked std and ltd in client state and its massively to the plus side and exponentially greater than any other project.

Very odd indeed and I agree with Stefan - why should setting the log flag work? But it has for me......on 3 boxes now!

Maybe it is not the flag, but something else I did in the process. So here is a description of exactly what I did in case it's different:

Leave client and science apps runing.
Edit cc_config file and save overwriting existing file (after taking a backup!).
Suspend each project from the Projects tab.
Disconnect from the active client by using Advanced>Shutdown Connected Client.
Close BoincManager.
Verify Boinc is not running using System Monitor.
Start Boinc.
Start BoincManager.
Resume projects from Projects tab.



Edit: maybe it is the suspend/shutdown/start/resume process?

I just ran the process described above on a Vista machine. This box has no cc_config file and I did not add one. After suspending, shutting down,re-starting and resuming as above, it appears to be working normally: 20 minutes elapse with no pre-empting or switching. Two CPU tasks, plus a GPU unit running.

---

Very odd indeed and I agree with Stefan - why should setting the log flag work? But it has for me......on 3 boxes now!

Maybe it is not the flag, but something else I did in the process. So here is a description of exactly what I did in case it's different:

Leave client and science apps runing.
Edit cc_config file and save overwriting existing file (after taking a backup!).
Suspend each project from the Projects tab.
Disconnect from the active client by using Advanced>Shutdown Connected Client.
Close BoincManager.
Verify Boinc is not running using System Monitor.
Start Boinc.
Start BoincManager.
Resume projects from Projects tab.

The log flag is off by default. You setting it to zero does nothing. If turned on all it does is log messages. It has nothing to do with your edit. Why, because I already have that set off and still am having problems.

By shutting down you have reset cleint and cleared the bug, It will begin to misbehave again when whatever is triggering the problem happens.

You could simply use in boinc manager, advanced > read config file, without shutting down.

Yes ETA it is 5-10 times higher than any individual project and over 30% higher than the total ....but I will crank it up even more....good idea

I find this odd, when was testing before and had a problem running GPU work, I found lowering the resource share to work.

I had something like
A=64
B= 8
GPU=768

When I lowered GPU to 256 it began running again. I've kept it there since and all testing went will, with 6.3.15, with it set lower.

It has now resumed the task after increasing resource(may or may not have anything to do with it)and should run to completion if my other quad is any indicator....it is at 95% complete now and I suspect it will not start another task immediately but will go to waiting again for a few hours ...will let you know

PROBLEM solved:

now working as expected with vista 64 bit. Why? Don´t know - maybe the WUs themselves got some internal logic?

No slowdown anymore, GPU Process stays at 16% average CPU time and the remaining 8-9 are consumed by other projects.

VERY nice job!

The task completed.....5 minutes later it started another for 30 seconds and is now waiting to run again.No joy in Mudville :(

now it had me 2 - 1 GPUgrid WU running, 3 on the bench and boincman deciding not to download work for other projects. solved this by cleaning up the bench and increasing work-buffer..

this whole logic is totally fouled up. unless boinc learns to handle resources for different projects seperately, it will never work. :(

After playing around with my Linux hosts today what I have found for what it is worth is the more task switching you can get the client to do the more liklihood that it will kickstart the gpu task to run to completion....any reboots or client shutdowns will usually put it back to waiting otherwise if it runs more than 30 secs it goes to completion.

I have set my local preferences as low as 5 min to switch and made sure I had multiple projects with work and the gpu downtime is then usually less than 1/2 hour....glad its sunday and not mid-week.

Doh!....Yes of course! Don't think I wasn't thinking straight earlier today....

Anyway, perhaps an important thing which might help trying to locate the source of this problem: it is happening here on 6.3.10 on Linux and Vista32 (I have no rigs higher than this), so tracking it down between 6.3.15 and .17 as suggetsed in the 6.3.17 thread might not be so easy.

I was out of circulation for most of last week: What else changed in between: the app I think?

---

Please put back <1 to 1 cpu

with other tasks running [4 seti +1 gpu] the gpu gets starved of cpu time on vista x64

went from 6 hours a wu to over 10 hours with cpu<1 on nvidia 280gtx

it is worth sacrificing 1 cpu for better speed

Please put back <1 to 1 cpu

with other tasks running [4 seti +1 gpu] the gpu gets starved of cpu time on vista x64

went from 6 hours a wu to over 10 hours with cpu<1 on nvidia 280gtx

it is worth sacrificing 1 cpu for better speed

I agree. But maybe not all of users would like to have the same. Mby best solution will be to give a choice to the ppl? I am thinking about one more functionality in BOINC Manager (to chose <1 or 1). It`s just an idea :).

---

We have tested this and it should not happen.

gdf