CPU <-> GPU rebranding

[Raistmer]

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!

Well, thanks of course but actually you probably using Rebranding tool written by Marius So passing congrats to him

[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.

[Franz]

Hi,
I see a little problem
Reschedule seems to work only the first time I run it.
I don't know what slots are but yesterday evening I had 3 slots and this morning 5
Reschedule was active all night but didn't have made his automatic job.
So I ended and restarted it. And works fine, moving to GPU a lot of Job.
CPU asks for new job and get itm but Rescheduler (in Test) is not able to see the new job.
So I end it again and restart. Now working.
It seems that you do some routine at the begining of the run and not at any Test or Run command.

Second question
In this PC, very strange, BOINC is asking job only for CPU.
http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049
I have resetted the project yesterday afternoon and receved a few GPU task. Then nothing.
Can you have any idea about this?
GPU is working only because I use rescheduler.exe

Bye,
Franz

[Franz]

Second question
In this PC, very strange, BOINC is asking job only for CPU.
http://setiathome.berkeley.edu/show_host_detail.php?hostid=2979049
I have resetted the project yesterday afternoon and receved a few GPU task. Then nothing.
Can you have any idea about this?
GPU is working only because I use rescheduler.exe

This problem now is solved. I See that now BOINC is asking job for CPU and GPU.
Non job in theese days but this is another case.

The first problem is still open.

Franz

[Franz]

The first problem is still open.

Franz

Is rescheduler.exe able to "see" setiathome_enhanced 5.28?
Franz

[Raistmer]

hardly...

[Samuel]

@Marius

Are you still developing your tool? My client_state got truncated in the middle of another project's data when I ran it (v1.9) the other day. The rebranding itself went fine and no errors were reported. The only actual loss was the time spent on the tasks that were running at the time (because the <active_task_set> part was gone).

I didn't want to revert to the backup because after restart BOINC fetched more MB tasks for the GPU. I should have realised something was wrong when it ran benchmarks but I just left it alone as I normally do.

I have the before and after client_state files if you're interested.

[Archangel999]

where i had wrong ?
 no application is running on gpu
x64 xp q6600 gtx nvidia



Reschedule version 1.9
Time: 09-09-2009 02:13:39
User forced a reschedule
Option "Only VLar+VHar to CPU" is enabled
Stopping BOINC application
BOINC application is stopped
Boinc applications
setiathome_enhanced 603 windows_x86_64
setiathome_enhanced 608 windows_x86_64 cuda
CPU tasks: 276 (95 VLAR, 3 VHAR)
GPU tasks: 0 (0 VLAR, 0 VHAR)
After reschedule:
CPU tasks: 276 (95 VLAR 3 VHAR)
GPU tasks: 0 (0 VLAR 0 VHAR)
Starting BOINC application
BOINC application started

[Raistmer]

try to change cpu/gpu % ratio

[Archangel999]

it is locked can't but transfer 15 unit to do gpu today but they aren't enough

[Raistmer]

Disable "OnlyVLAR+VHAR to CPU" check box (and read description that appears on "mouse over")
With this box enabled app will care ONLY about VLAR+VHAR leaving your GPU idle if no VLAR or VHAR to move.
So if you wanna move "usual" tasks around - you need to disable this option.

[Archangel999]

Raistmer all working fine thank you !