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

a- Yes, as I said before, I get the "got 0 tasks"

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

---

Scanning for our furry friends since Jan 2002

··· 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

Yes, what I have set in red is exactly what I get when I make a manual update.

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.

I understand the idea, but when I do a request manually, I get no WU, so I think that the fact that they are made automatically doesn't matter: I'll get no WU again. Or not?

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).

That´s the reason why your client won´t ask for new work on GPU-Grid.
It thinks, that GPU-grid has it´s share on projekt time and so he doesn´t request new work for it. After several ours idleing the CPU-projects seem to catch up and the GPU-Project gets new work. I don´t know exactly how that is calculated, but it could be based on the Credits you get for a processed unit. On GPU-Grid they are much higher because of the massive calculating power of the gpu and so the scheduler starts to give the other projects more time to get them on the same level.

Just set the resource-shares here on your GPU-grid acount (under your account) to 1000 and everything should work. Of course there is still the problem that you only gets 2WUs because of the 1 WU per CPU-Core Limit (I hope that gets fixed some time - as it´s really annoying to Dual-Core PCs)


Cu KyleFL

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...

What's your current ressource share?

MrS

---

Scanning for our furry friends since Jan 2002

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.