I infer that when my BOINC client reports this....

10/9/2009 12:04:44 PM GPUGRID Sending scheduler request: To fetch work.
10/9/2009 12:04:44 PM GPUGRID Requesting new tasks for CPU
10/9/2009 12:04:49 PM GPUGRID Scheduler request completed: got 0 new tasks
10/9/2009 12:04:49 PM GPUGRID Message from server: No work sent

...that the actual issue is that there are no GPU work units (though I still don't understand why there isn't a 'requesting new tasks for GPU' message in this situation). Current server status is 'all green'.

http://www.gpugrid.net/server_status.php

In the column headed 'Database/File Status', currently there are 3,290 "GPU Results Ready to Send", and "4,546 Results in progress". Not sure what either of these mean, for sure. I'm guessing that the 'results in progress' are the WUs that are out being cruched by us...so that might mean that the 'GPU results ready to send' is the available work...but then again, this is one of those times when I'm not getting any work.

SOOOOOO....a couple of things: can a help button be added to the status page explaining what these things are; but more importantly, is there a clear and simple way of displaying whether work is available or not?

Apologies if this is obvious to everyone else, or if it's been covered in an old post...but then again, maybe I'm not the only one wondering.

It means that work is available for a GPU (an appropriate Nvidia chip, usually on a graphics board) but not for a CPU (your computer's main processor).

The request was for work for a CPU, so that's what you got an answer for. You may need to wait until it requests work for a GPU instead to see something useful happen. If you aren't close enough to needing another GPU workunit to keep your GPU busy, BOINC won't ask for any.

I'm not sure if GPUGRID has ever offered workunits that will run on a CPU only; they definitely don't now.

'GPU results ready to send' is the work ready to send, although often not all of them match your computer well enough that it can simply pick any of them.

Workunits are considered in progress if they have been sent to computers that haven't yet done the final step of returning the outputs, and haven't reached their deadlines yet.

A number of other BOINC projects have only CPU workunits to offer; you'll get similar results if BOINC decides to ask one of them for GPU workunits.

'Results' means the results of the software for creating workunits, not the results of what your computer does with them.

If BOINC decides not to ask for GPU workunits when none are in progress on your machine, this means either that you don't have an appropriate GPU, or you don't happen to have told BOINC to try using it.

There's something more to it than that. No changes in the system....it has been crunching GPU work units for several weeks, and now I have a second NVidia-equipped system. From time to time, they both have this same issue: no GPUGrid work to do in the queue (so the GPU moves on to crunch SETI GPU work.) Meanwhile, the BOINC client keeps asking GPUGrid for CPU work, never asking for GPU work. I suspect this is due somehow to GPUGrid having no work for whatever reason. The usual pattern is that at some point, a GPU request will magically yield new work, and all will be well.

I think this may be a combination of quirky BOINC client behavior and no work on GPUGrid, but I have no way of knowing. I'm looking for some insight and some transparency.

So my other system finished it's GPUGrid WU overnight, and it, too, started requesting CPU work. Then this morning the first system suddenly asked for a GPU wu, and received it.

It seems like rather random behavior if you asked me.

Okay, here's a theory that I just tested once (and it seemed to work):

First, I did update the resource share...pushed GPUGrid from 100 to 500. Still no luck. Then I looked in the work queue: SETI (cuda) was running a job on the GPU (which normally take 20-30 minutes on my 9800 GTX+), with 3 more ready to run behind it. On the theory that the BOINC client wasn't asking for GPU tasks from GPUGrid because of the number of SETI GPU tasks in the queue, I aborted all of the unstarted SETI tasks, did an update with SETI to report them (and confirmed that they had exited the queue), and immediately the BOINC client asked GPUGrid for GPU work.

I'll confirm this after I've had a little more experience with both machines.

Close, but not quite right.

Resource share doesn't measure the number of tasks you have done in the past, but the total amount of time you've spent on the two projects. Even with equal resource shares, you would expect to do many more of the (much shorter) SETI tasks between each GPUGrid task. If you leave it alone for long enough, you should see that the time spent on each project is in proportion to your resource share settings.

Second, there was no need to abort the SETI tasks to perform that experiment - you could have just suspended them, and come back to finish them off later. SETI is extremely short of cash, and has to pay for everything out of donations: that includes the internet bandwidth used for downloading datafiles. Although the actual cost of forcing someone else to download those tasks again (to replace the ones you'd already downloaded) is tiny, it would in general be regarded as polite not to put any more strain on the SETI servers and cash resources than is strictly necessary.

In fact, suspending probably would not have shown this result, as the projects I aborted were 'waiting to start' (ie, 0.00% complete.)

Doubtful that there is a measurable incremental cost to SETI as a result of my throwing two fish back in the pond. In any event, I don't really care to be lectured about aborting 2 work units after I've supported SETI for 10 years. It's not about being frivolous, it is about troubleshooting so that I can also support GPUGrid, itself a resource-constrained project that also needs the support I can provide. Happy to have your technical input, but please save the sermons.

Yes they (probably) would. Been there, done that.

I, too, have crunched for SETI for over 10 years, and that's where I've learned most of what I know about BOINC. It works (for the purposes of this particular discussion, i.e. about when, and what, it decides to request next) by keeping track of the amount of work available to run - the cache, in common parlance.

Suspending the SETI tasks would have served two purposes:

1) Reducing (temporarily, not permanently, but that's good enough) the amount of work in the cache. That would have made BOINC more likely to request work.
2) But while a project (SETI, in this case) has a suspended task, BOINC won't fetch work from that project. So that would have increased the chance of getting a GPUGrid task (the object of the exercise), whether it was really ready to ask for one next or not.

To really understand (and even predict) what BOINC is going to do next, the best trick is to enable "Work fetch debug" logging using a cc_config.xml file.

Always easier to make a precision diagnosis in hindsight, isn't it? Seems like a lot of fuss for two recycled SETI WUs. I'm just trying to share some experience with other GPUGriders who might have the same problem. Thanks for the lecture. Roger and out.