Forum > GPU crunching
CPU <-> GPU rebranding
Raistmer:
--- Quote from: Fredericx51 on 20 Aug 2009, 10:57:47 am ---Hi , I never had a problem , stopping BOINC, even when using the sleep mode ,availeble when right-clicking on the tasbar - icon.
Never had to use net stop boinc, so time to install this tool, too ::)
You've done a great job Raistmer!
--- End quote ---
Well, thanks of course ;) but actually you probably using Rebranding tool written by Marius :) So passing congrats to him ;D
Geek@Play:
I have been watching this computer for some time now and noted that it never crunches any AP work. All 4 of my boxes are set up the same and 3 do occasionally crunch AP this one does not. I also noted that it always asks for work for the GPU and never requests work for the CPU which may explain why AP work is never assigned. I have the rescheduler set to run 2 times a day with the slider set at 50. This morning I set the slider to 75 but this one computer is still only requesting work for the GPU. Seems the rescheduler is sending the VLAR work to the cpu's as it should but it seems to never get them done, always downloads more VLAR work which get's reassigned to the cpu's.
Do I have to live with this and wait until the VLAR work is reduced and then see if it requests work for the cpu's? I don't believe I will get any AP work until it actually requests work for the cpu's. Is this the way it is??
From last run of reschedule.....
---------------------------
Reschedule version 1.9
Time: 03-09-2009 12:00:00
User forced a reschedule
Stopping BOINC service
BOINC service is stopped
Boinc applications
setiathome_enhanced 603 windows_intelx86
setiathome_enhanced 608 windows_intelx86 cuda
CPU tasks: 196 (196 VLAR, 0 VHAR)
GPU tasks: 617 (125 VLAR, 196 VHAR)
After reschedule:
CPU tasks: 321 (321 VLAR 0 VHAR)
GPU tasks: 492 (0 VLAR 196 VHAR)
Starting BOINC service
BOINC service started
Jason G:
Some possible thoughts on that:
This might be a case where attempting to stabilise the Duration Correction Factor with the <flops> entries can help. The behaviour I see when this is achieved, is swapping WU for WU, that is report 1 request 1.
Now it gets more complicated, as you point out, because the GPU requests large chunks of work, which a largish proportion lately seem to arrive as VLAR, which then up to twelve hours later get rescheduled to CPU, oversubscribing its queue & generating another GPU fetch.
I would suggest in this situation, a DCF instability would magnify the difficulties (oscillation), since completing one GPU WU would throw the mechanism into 'underestimate mode', effectively enabling fetch for GPU again, since that's the one that just finished, and CPU still has plenty of VLARs to chew on (GPU probably fetched because a big chunk of its WUs just got shunted away).
Correcting the instability, if truly present, might have the following effect IMO: CPU WU time estimates, upon completion of a VLAR WU, no longer throw the system into 'overestimate' mode, so won't disable CPU work fetch right when the CPU probably needed it. That would probably be 'in between' the times that the GPU fed it VLAR tasks, since VLAR tasks were probably assigned at reschedule time, and take a-couple-of/a-few hours.
So the opportunity for the CPU to fetch for itself is from a few hours after reschedule, right through to just before the next reschedule. It generally won't do this if the tasks it has just been finishing violently threw time estimates off ... So it waits too long... until after the next reschedule.
For DCF stability reference, my comparatively lower end E8400 dual core w/9600 GSO runs with a DCF ~0.3 +/- 0.02, and fetches CPU tasks as soon as it finishes one, which rescheduling large numbers of VLARs temporarily stalls.
I'd imagine that a Q6600 w/ GTX 260 like that might be harder to stabilise due to greater CPU/GPU performance difference, but that's just guessing since I own neither device.
Jason
[Later: Doh! doing some offline testing, forgot to deactivate my reschedule & managed to trash a lot of work mostly due to panic when it restarted Boinc in the middle of my testing ::) ... Machine no longer suitable reference model :'( ]
Pappa:
I agree with Jason about DCF... My AMD X2 6000 (Seti Beta Stcok app's) hates MB 6.03's . If it runs just Cuda (I keep trying) the DCF is 1.4 as soon as it snags a MB 6.03 DCF torques to 3.5. So that would be the example of the wider instability.
Using Optimized with the <flops> it normalizes so that the swings are not a bad.
Al
Geek@Play:
Appreciate the comments. I have used the <flops> values but perhaps they need to be reifined better to reflect the true crunch times of each app. Will keep trying.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version