Nice! I'll try this later @ home and report... :)

GPUGRID is now requesting less than one processor such that people can run a further cpu job.
This will stay if there are no problems. People should not use ncpus anymore and update to clients 6.3.17 or 6.3.14.

GDF

Any idea when 6.3.17 for Linux64 will be out ? 6.3.14 won't work for me...

Any idea when 6.3.17 for Linux64 will be out ? 6.3.14 won't work for me...

Hehe, yea it's now <1...
BOINC shows 0.90 CPUs, 1 CUDA.

BOINC also shows 4 CPU tasks running plus 1 PS3GRID, but the taskmanager shows:

3 Einstein tasks with each 25% CPU
1 Cosmo task with 25%
and all few seconds I can see the acemd task kicking in with 1 or 2% CPU.

Is this how it should work?
I would think with 0.9 CPU the PS3GRID task should get more of the CPU?

[edit]Using 6.3.17, of course without ncpus+1[/edit]
____________

pixelicious.at - my little photoblog

Do we need to wait for new work for this to take affect?

I am seeing "Running (1.00 CPUs, 1 CUDA)" on 6.3.17

Hehe, yea it's now <1...
BOINC shows 0.90 CPUs, 1 CUDA.

BOINC also shows 4 CPU tasks running plus 1 PS3GRID, but the taskmanager shows:

3 Einstein tasks with each 25% CPU
1 Cosmo task with 25%
and all few seconds I can see the acemd task kicking in with 1 or 2% CPU.

Is this how it should work?
I would think with 0.9 CPU the PS3GRID task should get more of the CPU?

[edit]Using 6.3.17, of course without ncpus+1[/edit]

Hehe, yea it's now <1...
BOINC shows 0.90 CPUs, 1 CUDA.

BOINC also shows 4 CPU tasks running plus 1 PS3GRID, but the taskmanager shows:

3 Einstein tasks with each 25% CPU
1 Cosmo task with 25%
and all few seconds I can see the acemd task kicking in with 1 or 2% CPU.

Is this how it should work?
I would think with 0.9 CPU the PS3GRID task should get more of the CPU?

[edit]Using 6.3.17, of course without ncpus+1[/edit]

Do we need to wait for new work for this to take affect?

I am seeing "Running (1.00 CPUs, 1 CUDA)" on 6.3.17

The 6.3.17 is working fine.

One Problem with vista 64. Without admin rights only three task + ps3grid are running on a quad. With admin rigts there are 4 task + ps3grid running.

any help?
____________
Constant dripping wears away the stone. :)

Yes, that is correct behavior.

The 0.9 can be any number less that 1.

If you check all CPU only jobs will run at low system priority.
CUDA/CPU=1 will run at low system priority
CUDA/CPU<1 will run at normal system priority.
This is for windows, i do not know how linux call it, but CPU<1 should run at a higher priority than the others.

In the future when there are more projects and more GPU's the CPU<1 percentage will matter, but for now with only one project it does not, as long as it is less than 1. I think the goal will be to use up to physical CPUs + 0.99

The 6.3.17 is working fine.

One Problem with vista 64. Without admin rights only three task + ps3grid are running on a quad. With admin rigts there are 4 task + ps3grid running.

any help?

Admin rights shouldn't be necessary!

I have 4 CPU tasks plus one GPU running on my Vista64 box. Just wait a little bit until the next task switch, the changes don't happen immediately. Or maybe restart BOINC...
____________

pixelicious.at - my little photoblog

Admin rights shouldn't be necessary!

I have 4 CPU tasks plus one GPU running on my Vista64 box. Just wait a little bit until the next task switch, the changes don't happen immediately. Or maybe restart BOINC...

Now for Linux I have a Q9550 running 4 cpu tasks and the gpu is always waiting to run 0.90 cpu,1 CUDA ????It starts up correctly but in 30 seconds or so it switches the CUDA app to waiting to run. Tried BOINC 6.3.10 & 6.3.14 same effect, Also the system monitor is showing only about 80% of resources are being used.My other Q9550 box is running correctly 4 cpu's and 1 0.90cpu,1CUDA for 5 total threads and 100% utilization...

What happenned? What can I do?

Hmm... Now I also have only 3 CPU tasks and one GPU task running...

I'll set up cc_config with a few debug flags tomorrow morning to set what's happening.
____________

pixelicious.at - my little photoblog

Now for Linux I have a Q9550 running 4 cpu tasks and the gpu is always waiting to run 0.90 cpu,1 CUDA ????It starts up correctly but in 30 seconds or so it switches the CUDA app to waiting to run. Tried BOINC 6.3.10 & 6.3.14 same effect, Also the system monitor is showing only about 80% of resources are being used.My other Q9550 box is running correctly 4 cpu's and 1 0.90cpu,1CUDA for 5 total threads and 100% utilization...

What happenned? What can I do?

@ Keith - 6.3.17

Now I have four CPU and one GPU task running again. But it's to late for me to set up the debug stuff and watch BOINC... ;) Will do that tomorrow...
____________

pixelicious.at - my little photoblog

@GDF
Maybe you should wait until an official 6.3.17 linux is made, as the last one I see is 6.3.14 on the dl page. Maybe you should switch back to CPU=1 until one is released, unless you have one all linux users can download.

So far except for a very brief period all I've ever seen on my Box's is 4 Wu's running. On 1 there were 5 running for about 5 minutes & then that was it, 4 on that Box too ever since, running 6.3.17 on all 5 of my GPU CUDA capable Box's.

@ Keith - 6.3.17

Now I have four CPU and one GPU task running again. But it's to late for me to set up the debug stuff and watch BOINC... ;) Will do that tomorrow...

So far except for a very brief period all I've ever seen on my Box's is 4 Wu's running. On 1 there were 5 running for about 5 minutes & then that was it, 4 on that Box too ever since, running 6.3.17 on all 5 of my GPU CUDA capable Box's.

Yup Keith, that's on the Vista Ultimate 64 bit box, with BOINC 6.3.17.
____________

pixelicious.at - my little photoblog

hmm - i'm running fiesta x64u too (6.3.17) - 4 ABC-WUs and 1 Cuda - the only thing is that 1 of the ABC-tasks is suspending from time to time.

running XP32 SP3, was running fine, 4 3x+1 wu and 1 GPU with ncpu+1. I removed the ncpu+1, installed BOINC 5.3.17, restarted, let it go through a completed gpu wu, it's now running 3 3x+1 and 1 GPU grid wu
____________
Team Starfire World BOINC
IRC- irc//irc.teamstarfire.net:6667/team_starfire

Do we need to wait for new work for this to take affect?

I am seeing "Running (1.00 CPUs, 1 CUDA)" on 6.3.17

Yes, any exsiting work you have will run at what ever it was sent at. You will notice the change was new work starts to download, although there may still be some work in the server queue at the old setting.

confirmed in my team, all three machines using 6.3.17:

working on two xp 32 bit machines as expected

NOT working on my vista 64 bit machine (instead 16-18% CPU, task gets only 1-2%, CPU Tasks get 24-25% each, slowdown as expected). Therefore im still using ncpus=4 till this is resolved.

With 4 cpu tasks running, 1 gpu task running (high priority). Unfortunately, taskman shows the GPU task running at the same priority as the CPU task, so is going to fight the cpu.

GPUGRID is now requesting less than one processor such that people can run a further cpu job.
This will stay if there are no problems. People should not use ncpus anymore and update to clients 6.3.17 or 6.3.14.

GDF

I would say use 6.3.17. So far no problems. I did extensive testing with 6.3.15 with no problems as far as job scheduling, testing both CPU=1 and CPU<1 jobs, which always ran and ran the proper number of other CPU only jobs. 6.3.17 should be the same as far as that goes.

6.3.14 will work some, but eventually it will leave no GPU tasks running, or only a GPU running. It does not behave well.

I have Boinc .14 that was running 5 tasks set by the ncpu flag.

After noticing the .9 CPU 1 cuda switch the project now runs 5 cpu tasks and 1 GPU.

I've deleted the cc_config file and now it runs 4 tasks plus 1 GPU.

The GPU consumes 2% to 5% of the CPU.

Already noticing the 30% performance increase, my daily 9500 credits jumped to the 13000s.

Bottom line, good work, although I'm hesitant to switch to boinc .17

Without admin rights only three task + ps3grid are running on a quad. With admin rigts there are 4 task + ps3grid running.

Klat,

I think I've seen the same behaviour as you did when I switched to 6.3.17 yesterday. BOINC manager showed 3 CPU + 1 GPU task running on my quad. However, there's a minor screen refresh issue where the manager shows a task as "ready to run" whereas in reality it's already started. I checked with task manager: 4 CPU and 1 GPU were running, although the 4th CPU task almost didn't get any CPU time, overall utilization was 93%.

After this night everything is running as expected, though. Didn't change anything. Now it's 4 CPU + 1 GPU, cpu utilization 100% and the GPU task taking between 9 and 22% (one core 25%). GPU temperature seems to be the same so I hope it's still running full throttle.

MrS

From the logs it looked like it has to do with the preemption of tasks, but I'm not a dev, I only report what I see... ;)
____________

pixelicious.at - my little photoblog

Would like to report back that under Linux and 6.3.14 the gpu task did eventually start and run full time,but it was a different task as I aborted a few that would only run 30 secs every 30 min...since it is on a 9800GT it is only 75% complete and will report back what happens as it completes to start the next one.

Edit-Bad news...my other host running CUDA on Linux is exhibiting the same behaviour as in waiting to run.....4cpu's running gpu waiting :(...I hope they release a new client soon for Linux...

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:

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.

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

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

Same problem here with my GTX280. The real running time is changing on Vista 64bit from 24000 sec to 34800 sec, now my GTX260 is much faster on XP 64 bit. Normally it should be reverse.

GTX280 http://www.ps3grid.net/results.php?hostid=7785 on Vista 64 bit
GTX260² http://www.ps3grid.net/results.php?hostid=13337 on XP 64 bit


____________

We have tested this and it should not happen.

gdf

We have tested this and it should not happen.

gdf

Please put back <1 to 1 cpu

We have tested this and it should not happen.

gdf

Same for the scheduler in 6.3.18, I described my problem in that thread.
6.3.14 + CPU setting of 1 and cpus +1 was the best solution for me so far, under Linux...
Since we are on 0.9 the scheduler is behaving strange...

edit:

ok, haven't seen your post, so I'll wait ;-)

I couldn't manage to make GPUGrid work (always idle dammit) since the CPU request change but it solved the issue by himself last night: WU got into high priority mode and started running. Now I'm on a tight schedule so it keeps working.

But I have to say that since the change my PC have become EXTREMELY MORE SLUGGISH. To the point that I could consider detaching from the project. I also tried lowering the process' nice value but it didn't do any good.

Yes, thats one thing I forgot to mention, which bugs me a lot...

On a desktop machine that is actively used, a nice value of 0 for the acemd process is to high. The system feels sluggish...
5 is fine for me, but most of the time I put it back to 19 and only when I leave the computer for some time I switch it to 0.

On my dedicated cruncher, its running at -5, but that one is headless ;-)

If you want to set some nice value to be set automatically, just put the following to roots crontab:

* * * * * renice 19 `ps -ef | grep acemd | grep -v grep | awk '{ print $2 }'`

I know that it doesn't use much of the CPU, that's not the problem, the problem is the priority...

Low priority (like 19) - desktop is responding quickly and feels smooth
current default priority of 0 - the desktop feels sluggish

Yesterday I wrote, that my GTX280 on Vista 64 need 34800 sec for one WU. I had reboot the Vista PC and the next WUs are runung with

26676.869 s and
25396.466 s

Looks like a longer uptime makes the calculation slower. Then Vista 64 bit has to reboot often to shorten the calculation time and XP 64 has to boot to clean up the GPU memory.

____________

I know that it doesn't use much of the CPU, that's not the problem, the problem is the priority...

Low priority (like 19) - desktop is responding quickly and feels smooth
current default priority of 0 - the desktop feels sluggish

Looks like a longer uptime makes the calculation slower. Then Vista 64 bit has to reboot often to shorten the calculation time

Are you basing this supposition on one single incident?

MrS

I have been getting consistent 26ms and 22000-23000 total runtimes out of my GTX260 EVGA card in Linux Hardy 8.04 latest 2.6.24.21 Kernel.Default is Nice 19 priority btw. My runtimes seem a bit shorter than most other 260's out there that post their numbers.(216 shaders) I have not seen any slowdowns or longer tasks.For me the optimizations so far keep making the tasks run shorter and shorter :)

Yes, thats one thing I forgot to mention, which bugs me a lot...

On a desktop machine that is actively used, a nice value of 0 for the acemd process is to high. The system feels sluggish...
5 is fine for me, but most of the time I put it back to 19 and only when I leave the computer for some time I switch it to 0.

On my dedicated cruncher, its running at -5, but that one is headless ;-)

If you want to set some nice value to be set automatically, just put the following to roots crontab:

* * * * * renice 19 `ps -ef | grep acemd | grep -v grep | awk '{ print $2 }'`

you need to become root, or use sudo to start the crontab command as root...
As user you call sudo crontab -e, then it depends on which editor is the default one on your system. Some use pico or nano, which are almost self explaining, as they have the key combinations listet at the bottom. Other distribution use vi, then you should look for a vi tutorial or set the editor variable to a more simple one.

Dont edit roots crontab file (should be somewhere in /var) directly, its better to use crontab because its doing some checking on what you entered and warns you if something is missing...