Forum > GPU crunching
CPU <-> GPU rebranding
Samuel:
--- Quote from: Marius on 05 Jul 2009, 12:18:06 pm ---Thanks for clearing this up, this could/will save lots of rebranding compared to the current version. And thank you samuel7 for reminding me about it! (so logical when you hear it afterwards :()
--- End quote ---
You're welcome!
My cuda queue is 80% VHAR, so won't run your program now. Waiting for v1.9 with VLARonly... ;)
Marius:
--- Quote from: Josef W. Segur on 05 Jul 2009, 02:16:53 pm ---Obviously the rebranding should either handle both cleanly, or be recoded to not affect Beta. The problem is that client_state.xml is only similar to real XML and the parts which apply to different projects are only separated positionally rather than being isolated properly by tags.
--- End quote ---
LOL, the current xml is indeed kind of a clumbsy approach and i believe they are very well aware of it and are going to change it (over time). Sofar not much harm, it just needs some work on my side ;)
SETI-GPU-process:
--- Quote from: BANZAI56 on 05 Jul 2009, 11:33:51 am ---Am I the only one having trouble downloading this?
Can't get 1.7 or 1.8..says IE can't d/l from site...
Any other link to it available?
--- End quote ---
I downloaded ReSchedule 1.8 about 6 hours ago and just did so again 3 minutes ago, just to make sure. Using Firefox 3.5 under Vista x64.
Unfortunately, currently I have no SETI work units to try out ReSchedule. :(
Purple Rabbit:
--- Quote from: Richard Haselgrove on 05 Jul 2009, 12:00:54 pm ---There's no actual need to rebrand VHAR. They run adequately on the GPU, and they don't cause any screen stuttering or other computer-use problems.
--- End quote ---
Ah ha (light bulb goes on)! I think this answers my question from a few days ago. VHAR doesn't error out with VLARKill 11, it just runs slightly (unnoticeably to a human?) slower. This could explain why moving VLAR/VHAR to the CPU, then moving 75% (with unknown, or unremembered settings) to the CPU only caused a little carnage with many more (ultimately successful) GPU tasks.
I apologize if someone patiently explained this to me previously. I just now understand. I sometimes need certain words in a special order :P
Rick
Brodo:
Also posted on the SAH Number Crunching Forum
BEWARE - UNEXPECTED SIDE EFFECT OF USING RESCHEDULE PROGRAM
Hi All
Reschedule works at the client level but if you use it to move 6.03 (CPU) units to the GPU when they are returned the server still thinks they were crunched by the CPU. As a result the server thinks you have one hellishly hot CPU and allocates extra units to the CPU accordingly.
Therefore if you have a slow CPU driving a fast video card you are likely to find that the CPU is allocated an impossible number of units for it to complete on time. e.g. I have a 3GHz P4 driving a GTS-250. When the dam broke and I was able to download units again I was allocated 349 units to the CPU and 200 to the GPU. These 349 units represent about a months crunching for the poor old P4. When I used ReSchedule to move some of these units to the GPU, as soon as I restarted BOINC it immediately set about downloading more CPU units to make up for the ones I had shifted.
So, if your using ReSchedule to move CPU units to the GPU be aware of this and keep an eye on the number of units that the server allocares and uploads to the CPU. At the moment I'm having to run "No New Tasks" to avoid CPU overload.
@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimise this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.
Thanks
Brodo
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version