I have a PC with two PCIe slots and a Nvidia GTX280 in each one. I have a two cores CPU, so I can crunch two WUs at at time in GPUGRID. The problem is that I'm not getting enough WU to be crunching continuosly. I can do 7 WUs a day in total, which is less than my 8 WUs a day limit. But I NEVER has any WU waiting to be crunched (in adition to those being crunched) and, STILL MORE, now I'm without any unit at all, with two GPUs doing NOTHING.

What can I do?

Is the project running short of units?

Other kind of BOINC projects that I'm running, have many WUs waiting to be processed.

I think he's running into the limit of 1 concurrent WU per CPU, not the overall quota (but increasing it to 10 is not a bad idea anyway). So with 2 cores and 2 GPUs he can't have a cache and gets idle time as soon as the WU-transfer and scheduler contact take some time.

MrS

Until "at least 2 concurrent WUs per CUDA device" get into scene, I have one GPU crunching for GPUGRID while the other one is crunching for FOLDING.

Similar prob over here: running two 9800 GX2 = 4 GPUs (and today was the first day they ran without errors)...and there are no WUs waiting...

Do you know how to teach BOINc to use only 1 of 2 GPUs?

MrS

I upgraded to version .14 and the problem with scheduling is worst now. I have been more than 24 hours crunching only one WU (one GPU crunching and one GPU doing nothing). Now my two GPUs are idle. It has spent more than 5 hours and there is no WU to crunch. Theoretically this PC can do more than 7 WUs a day if it would be fed constanly.

Why are you not getting new WUs? Your host sems to be this one, which has a daily quota of 10 (the maximum). Is BOINC not requesting new work or is the scheduler denying them?

MrS

When this happens to me, (hitting the 2 WU limit, which normaly only happens when the project is down) and my GPU goes idle I update the project once in the project tab. Then its immediatelly reporting the finished units and gets new ones...

What you could do is setting a task in the windows task planer (no idea how its really called), for the following command to be executed once each hour...

c:/path/to/your/boinc/boinccmd.exe --project http://www.ps3grid.net update

Its just a temporary solution until the projects hands out units based on the number of GPUs, not CPUs...

No, I tried it manually many times and the answer is "get 0 tasks". I only receive task when the scheduler wants...

Does BOINC ask for work if you click on the update button and you get the "got 0 tasks" answer from the server?

How does you resource share look like for PS3GRID and the other projects?
How have you set the options "connect to the internet every n days" and "maintain enough work for an additional n days"?
____________

pixelicious.at - my little photoblog

No, I tried it manually many times and the answer is "get 0 tasks". I only receive task when the scheduler wants...

Does BOINC ask for work if you click on the update button and you get the "got 0 tasks" answer from the server?

How does you resource share look like for PS3GRID and the other projects?
How have you set the options "connect to the internet every n days" and "maintain enough work for an additional n days"?

No, I tried it manually many times and the answer is "get 0 tasks". I only receive task when the scheduler wants...

I've just had the same happen on my quad core.
I got around it by suspending the other active project (seti) and then PS3Grid immediately requested more work.

I have just tried and YES, it has been to stop 3x`1 project and the client has tried to get WU inmediately, but it has get the "reached per-cpu limit...." (because I still have twuo units being processed). But at least it has tried to get WUs. So I'll leave stoped the other project and wait until I complete the running WUs... I'll report later.

··· Before a line like:
"11/10/2008 15:21:54|PS3GRID|Scheduler request completed: got 0 new tasks"

there should be a line like:
"11/10/2008 15:21:49|PS3GRID|Sending scheduler request: To fetch work. Requesting 6725 seconds of work, reporting 0 completed tasks"

If your BOINC wrote "requesting 0 seconds of work" we'd have found the reason for your problem (but not necessarily the solution).

MrS

Well then it is clear why you don't get GPUGRID tasks - BOINC doesn't ask for them... ;)

To make sure I always have enough GPUGRID tasks in the queue I have set the resource share for GPUGRID/PS3GRID to 1000.
All other CPU only projects have a resource share of 200 to max.600.

Then I have set a short "connect to internet" time of 0.1 and "maintain enough work for an additional n days" is set to 0.7.

That way I always have enough work from GPUGRID and also from other projects on my Quadcores.
It may still be a problem with a Dualcore and two GPUs, but BOINC should at least ask for more work from GPUGRID more frequently with such settings.
____________

pixelicious.at - my little photoblog

··· but BOINC should at least ask for more work from GPUGRID more frequently with such settings.

Well, to be honest - a manual update won't do any good. And suspending project a to get more work from project b won't help much either, because that way the BOINC scheduler will hardly ever "learn" how much work it has to fetch from which project... If you like to crunch more for one project than for another one, set the resource share for that project higher, and just wait...

But the main problem here at GPUGRID like it is now, is that you can only have as much tasks in the queue like you have CPUs.
Which means with a Dualcore you can always have only two GPUGRID tasks. Which wouldn't be a problem if you only have one GPU, but with two GPUs that's bad...

If you set a higher resource share and short connect to Internet intervals, you have at least (I hope) not to wait 9 hours until you get a new PS3GRID WU.

A better solution would be if GDF would change the max. WU per CPU setting to 2, but this might cause problems with Quadcores with only one GPU... So we all will have to wait until there is a server setting to allow x WUs per GPU instead of the x WUs per CPU like it is now.
____________

pixelicious.at - my little photoblog

How does you resource share look like for PS3GRID and the other projects?

b- 100% each project. I actually have 3x+1, but when the GPUs beguin to crunch, they stop (only two cores).

Recently the two WUs has been completed. The client load one more task and stopped. There was no other project running. I waited some time and tried what I has been told. I activated the 3x+1 project that was suspended. Waited a minute or so, and I suspended it again: Inmediately a new WU beguin to be downloaded. But it has a seious handicap: it has to be made manually...

Resource share = 1000 for gpugrid. 100 for all other projects.

It seems that now it works. I have checked just now believing that I would have to force the new WU manually, and I have been surprised by the fact that they both have been sent and the new ones downloaded automatically. The share=1000 seems to works. The other projecta were suspended too (which in this case is irrelevant because they will haven't work too).

I hope this repeats the next time.

Thanks you, thank you very much.

Well, with the "share = 1000" trick I can have WUs. But the total solution will arrive when I can have at least two WUs waiting to be processed (overpass the "1 per-cpu limit") to overcome the sometimes large amount of time elapsed since a WU download is complete, which implies that the corresponding GPU is idle.

It seems that it's necessary to have no CPU-BOINC project active in order that the upload/download process be without hours-lag.

I have suggested we need a GPU limit, like the CPU limit, but they need to be two different items, currently they are the same but only a CPU limit. It will be considered on how to do and may be in a future versions. This will avoid two problems, not getting enough work for GPUs when you have less CPUs than GPUs or getting to much work extra work when you have more CPUs than GPUs. In essence you should end up with always 1 running and 1 on standby for each GPU where you have enough CPUs to support them. The current way was jsut an extension of the exisiting CPU limits, which we have proved to be not sufficient.