I've been crunching GPUGrid for a couple of weeks. From time to time (and currently) I have no GPUGrid WUs. No big deal, as I have a queue of SETI cuda tasks....but the scheduler request message is curious...

9/22/2009 9:52:35 AM GPUGRID Requesting new tasks for CPU
9/22/2009 9:52:40 AM GPUGRID Scheduler request completed: got 0 new tasks
9/22/2009 9:52:40 AM GPUGRID Message from server: No work sent
9/22/2009 9:52:40 AM GPUGRID Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.

I don't know why BOINC (6.6.36) is bothering to ask for CPU tasks...("Hello! This is GPUGrid...GPU!"), and NOT requesting GPU tasks. Other stored messages show the scheduler request ONLY requesting a GPU task (and getting it.)

BOINC Manager issue or GPUGrid irregularity?

future builds and from 6.6.30+ are designed to ask for cpu and gpu work from projects..

this is to make sure that boinc manager is not one sided with the work request...

Right, unfortunately, the 6.6.30 and up clients DO NOT looks at the actual project/application settings to ask for the right type of work first. While this clearly comes to a surprise to the BOINC client developers (who perhaps develop but don't use what they make), there ARE projects which run CPU only tasks. The GPU query first creates unneeded I/O stress on a project (you't think the developers, being more than a tad SETI-centric would have a clue that this can be an issue). Also, for the many folks running mixed configurations (GPU plus CPU projects and hardware), this can also present a problem. For me it is at its worst with MilkyWay. MilkyWay is one of the two projects currently out there which supports CPU, ATI GPU and nVidia GPU. But for MilkyWay, the GPU requirement is double precision which rules out the vast majority of nVidia cards and ATI cards). OK -- so I configure for NO GPU work.

But does the brand new BOINC client have a CLUE about this -- nope, it madly goes after GPU work -- FIRST -- each time, and when it does this, it trips a retry timer for a 60 or 90 second backoff. Then 60 or 90 seconds later, it AGAIN goes to the project and AGAIN asks for GPU first.

When I have a workstation with no supported GPU's for any project, (even Collatz which support single precision CUDA cards down to the 8400 and embedded ATI down to the 3200), the solution is simple, go with the CLEAN 5.4.5 client.

If I don't want to work with Collatz on a workstation, but do want to run with GPUGrid -- I can still (for the moment), use the 6.4.5 client.

But on those workstations where I'm running mixed mode and have Collatz - which now requires Cuda 2.3, or have a supported embedded ATI card -- since these combinations REQURE the 6.10.x beta BOINC client, I encounter issues -- especially with mixed mode projects (like MilkyWay) where they support both CPU and GPU workunits.

Sorry for the rant, but I figure here is a decent place -- perhaps by posting this folks at GPUGrid, just might slow up the charge to 2.3 only support which compels use of the 6.10 client.

future builds and from 6.6.30+ are designed to ask for cpu and gpu work from projects..

this is to make sure that boinc manager is not one sided with the work request...

Sorry for the rant, but I figure here is a decent place -- perhaps by posting this folks at GPUGrid, just might slow up the charge to 2.3 only support which compels use of the 6.10 client.

Thanks for that -- perhaps the complex setup I have (I want GPU tasks for Collatz and GPUGrid, but not with other projects) causes the BOINC Client to be bewildered. Interesting enough, the problem I'm seeing is not on ALL my workstations, not even on ALL my XP SP3+ and 9800GT workstations. Some other variable might be in the mix.

Sorry for the rant, but I figure here is a decent place -- perhaps by posting this folks at GPUGrid, just might slow up the charge to 2.3 only support which compels use of the 6.10 client.

Well, v6.10.5 would be an excellent choise for Gpugrid, since you'll basically get an infinite cpu-deferral... but unfortunately your cpu-only-projects also has a tendency to get the infinite deferral...

But anyway, with v6.10.6 and later clients, a project can choose to give upto 4 weeks deferral-message for any hardware-resource, either cpu, cuda or ati.

Okay, I'm confused...boinc.berkeley.edu is showing 6.6.36 as the current release (for Windows.) What's with the 6.10.x releases you are mentioning? Beta?

Never mind...I see it.....the 'all versions' link. It is Beta.

Right -- Beta -- and the ONLY way you get Cuda 2.3 (along with the 190.38 or 190.62 driver). Collatz is actually forcing this with Cuda 2.3 only support. The plus with Collatz is that you can run entry level Cuda cards all the way down to an 8400GS and complete work. Also, Collatz has support for ATI GPU's -- all the way down to the embedded 3200 GPU.

Never mind...I see it.....the 'all versions' link. It is Beta.

Okay, I'm confused...boinc.berkeley.edu is showing 6.6.36 as the current release (for Windows.) What's with the 6.10.x releases you are mentioning? Beta?

True enough over here -- but as I noted, for Collatz if you have a CUDA card and want to play over there, you MUST have 6.10.x -- as earlier versions don't support CUDA 2.3 and Collatz REQUIRES 2.3 support for CUDA cards.

The only advantage and reason to use 6.10 right now is if you have an ATI card that you want to have supported like CUDA is with 6.6.x ... no ATI card no pressing reason to try the 6.10.x versions ... if you do ... 6.10.3 is the only one I can recommend until we see what 6.10.7 has in store for us ...

About 9 hours in, steadily running ATI work 6.10.7 seems to have corrected all the issues of .4 through .6 and added no new issues. It seems to even be better than my prior recommendation of 6.10.3 ... th=ough I stress again I am only 9 hours in and I have not been able to let it free-wheel yet (80 some Collatz tasks in suspend for the moment in that that is 25 hours or so of steady work ...)

I still think there is something wrong with the way they are calculating the debts though I don't have proof yet ... I think there is also a logic flaw in the way they are running all GPU work with strict FIFO being the rule ... for one thing, with multiple projects it looks like you cannot keep a good queue (balanced and full) of work for the GPU with the current rule set.