Advanced search

Message boards : Server and website : WU Availability: is there a reliable way to see this?

Author Message
Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13092 - Posted: 9 Oct 2009 | 16:18:49 UTC

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.

Profile robertmiles
Send message
Joined: 16 Apr 09
Posts: 503
Credit: 727,920,933
RAC: 155,858
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13095 - Posted: 9 Oct 2009 | 23:34:44 UTC - in response to Message 13092.
Last modified: 9 Oct 2009 | 23:58:32 UTC

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.

Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13096 - Posted: 10 Oct 2009 | 0:03:04 UTC - in response to Message 13095.

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.

Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13114 - Posted: 10 Oct 2009 | 12:26:27 UTC - in response to Message 13096.

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.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1957
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 13115 - Posted: 10 Oct 2009 | 12:30:29 UTC - in response to Message 13114.

There is (unfortunately) plenty of work queued in gpugrid.
So, it is quite strange that your computer does not request GPU work. Try to increase the resource share.

gdf

Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13117 - Posted: 10 Oct 2009 | 16:52:38 UTC - in response to Message 13115.

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.

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 1576
Credit: 5,597,961,851
RAC: 8,772,503
Level
Tyr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13118 - Posted: 10 Oct 2009 | 17:22:48 UTC - in response to Message 13117.

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.

Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13123 - Posted: 10 Oct 2009 | 21:03:23 UTC - in response to Message 13118.

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.

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 1576
Credit: 5,597,961,851
RAC: 8,772,503
Level
Tyr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13125 - Posted: 10 Oct 2009 | 21:27:00 UTC - in response to Message 13123.

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.

Cheech Wizard
Send message
Joined: 7 Aug 09
Posts: 16
Credit: 346,450,067
RAC: 0
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 13127 - Posted: 10 Oct 2009 | 22:51:15 UTC - in response to Message 13125.

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.

Post to thread

Message boards : Server and website : WU Availability: is there a reliable way to see this?

//