1) Message boards : BOINC Manager : My Wish List - part 3. (Message 31613) Posted 16 Mar 2010 by bburwood Post: You were right Gundolf. It's definitely the amount of free GPU RAM. I made a cc_config.xml file and saw the dreaded 231MB < 238MB message. So I dropped to 16 bit colour ... 236MB < 238 MB! Gggrrrr! 8 bit ... 238MB < 238MB!? I guess that one was borderline. I didn't try dropping the resolution, but that probably would have done the trick ... at the expense of a blurry image for everyday stuff - I don't think my mother would appreciated that! As for rebooting - it gets turned off (shutdown) every day so that shouldn't be an issue. As you've suggested I'll continue the quest for a few extra MB GPU RAM on the SETI CUDA board. That only leaves a new suggestion for the wish list (instead of my original misguided suggestion, which is probably already implemented anyway): that the client check the GPU RAM available against what the project will need *before* downloading a work unit, as seems to happen with normal work unit RAM requirements. Not sure how, or if it can be done in the client, but maybe when a project has a CUDA version available it might need to be required to say how much GPU RAM a work unit needs before that unit actually gets downloaded and assigned. IT seems to work ok for normal RAM requirements - perhaps some better checking is needed for CUDA RAM requirements? (so that thousands of workunits [~1050 in this case] don't get delayed by pc's downloading them that ultimately can't crunch them because they just miss out on having enough GPU RAM available.) bb from Oz.

2) Message boards : BOINC Manager : My Wish List - part 3. (Message 31606) Posted 16 Mar 2010 by bburwood Post: Looking at your sample messages with SETI apparently asking for 238MB of GPU RAM available, that is looking like the probable source of the problem. The card in question has 256MB total, but is running in 1650x1050x32bit mode, so there's a good chance of it using up enough RAM to stop SETI from running. The machine is also not the machine I normally use so I'll have to wait until I can use it to change settings and test. In the mean time do you have any suggestions as to how to reduce the GPU RAM usage, preferrably short of reducing the resolution, bit depth, or both, so as to minimise the impact on normal usage? (If I have to I'll drop the bit depth to 16 bit to get it to clear the backlog of units it already has, but I'd rather not have to do that as a long term thing. After that I guess I might have to disable cuda SETI at least for that machine. [my only cuda machine running it - until I can get myself a new box that will do it easily]) For extra info, it's not a machine that needs a hefty GPU in general, except for the Windows display resolution (the LCD screen native res, which I'd rather not change from for obvious reasons). Its heaviest load is probably the occasional flash game in Windows and once in a while (as in: only a couple of days every couple of months) C&C Generals. (but I'm guessing it will automatically not run when Generals asks for the card, and I can force it not to if necessary) It's running XP Pro SP3, 2GB RAM, and the recent 196.75 nVidia drivers - any tweaks there to reduce general Windows GPU RAM usage? (disable triple buffering and the like, perhaps) Thanks, bb from Oz.

3) Message boards : BOINC Manager : My Wish List - part 3. (Message 31588) Posted 15 Mar 2010 by bburwood Post: As a further explanation, let say in my case I have CPDN set to resource share 20 and SETI set to resource share 50. In the non cuda version that meant CPDN had a roughly 30% share of cpu time (or probably more correctly total long term amount of number crunching, or GFLOP's [not GFLOPS]) and SETI had 70%. Now I've added cuda to the mix I'm guessing it includes the cuda total in the 70% share for SETI meaning it hits that proportion much quicker, and then sits and waits for the cpu to slowly catch up the CPDN totals leaving the cuda SETI idle. If it counted them separately then that would give something like this: CPU processing share: CPDN 20 (~30%), SETI 50 (~70%) GPU processing share: CPDN 0 (since it is not a CUDA app), SETI 50 (100%) That way it could use Astropulse (from SETI) and CPDN for example to keep the cpu busy while cuda SETI would keep the gpu busy. That's how I see it anyway. bb from Oz.

4) Message boards : BOINC Manager : My Wish List - part 3. (Message 31587) Posted 15 Mar 2010 by bburwood Post: I've finally just installed a cuda capable boinc on a cuda capable machine (as part of a complete reinstall of that machine) and have come across my first feature request. I'd like boinc to separate its resource share allocation into cpu and gpu categories so that the gpu will continue to crunch all the time, regardless of the cpu project debt levels. Here's the example: the machine in question is just a Pentium dual core 1.6Ghz with an nvidia 8400GS card in it. BOINC picks it up and tells me it is 29GFLOPS peak capable and proceeded to download over 1000 cuda work units for SETI@home for it! (after it downloaded a few normal cpu units before it had finished getting the cuda executables) I let it finish the 2 SETI cpu units it started but aborted the 3 it hadn't started. I also attached it to CPDN and it grabbed 2 units for that and started crunching those. The problem is now it isn't touching the SETI cuda units at all (the non-cuda SETI units have finished now), and is only crunching the CPDN units, leaving the GPU idle with >1000 cuda units "ready to start". My guess is that it may have done some quick cuda crunching and now it's waiting for the non-cuda CPDN to catch up before doing any more SETI crunching. I have set both projects to not download any further work until it decides to do the SETI units, and I'll wait until the early deadlines for the SETI units pass before raising an issue elsewhere - to see if it goes into panic mode as the deadlines approach. It just seems to be a waste to have >1000 cuda units sitting in a queue with an idle GPU (even when set to use the gpu all the time), especially when that single gpu will likely be my biggest single GFLOPS contributor at present! bb from Oz.

---

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.