Well I just joined here at GPUGrid, and I was just trying to figure out what resource share I should give to GPUGrid, but realized that this is quite different than the RS of the CPU. So, even if I give a 1 resource share to GPU, it will still keep the GPU happy with 24/7 worth of work! So hence the question: since the RS of GPUGrid is different than that of the CPU, what RS should I give it since it will not matter? Or am I missing something here?

---

(Click for detailed stats)

RS is now applied to each "Class"of resource. Sadly the UI does not reflect this.

So, RS in the original meant that use this proportion for the CPUs... two projects with 100s meant 50/50 allocation ... 3 at 100 and 33/33/33 and so on ... those of us more creative meant that we could set 1% to 20% allocations depending on the mix of RS assigned to the projects attached.

Drop in a GPU and the RS now is mis-displayed because what it should show is the GPU Grid RS at what ever number against, in this case, no other projects... so 100% ... attach to Collatz or MW and the above rules apply (assuming you run GPU only work from those projects)...

Things get more complex if you are in fact able to run both CPU and GPU work from a project because the rules are supposed to allocate according to the proportional speeds of the CPUs and GPUs... In that no project (aside form perhaps Collatz) might allow this natively at this time I don't know any one that has tried this.

Also, all the 6.10.x versions and many of the 6.6.x (the latter ones) have also bent the RS as it applies to GPUs because GPU tasks are run in strict FIFO order ... I talk about this elsewhere and am too tired to go deeper unless you need it ... if so, ask and I will pcik up tomorrow when and if I can ...

RS is now applied to each "Class"of resource. Sadly the UI does not reflect this.

So, RS in the original meant that use this proportion for the CPUs... two projects with 100s meant 50/50 allocation ... 3 at 100 and 33/33/33 and so on ... those of us more creative meant that we could set 1% to 20% allocations depending on the mix of RS assigned to the projects attached.

Drop in a GPU and the RS now is mis-displayed because what it should show is the GPU Grid RS at what ever number against, in this case, no other projects... so 100% ... attach to Collatz or MW and the above rules apply (assuming you run GPU only work from those projects)...

Things get more complex if you are in fact able to run both CPU and GPU work from a project because the rules are supposed to allocate according to the proportional speeds of the CPUs and GPUs... In that no project (aside form perhaps Collatz) might allow this natively at this time I don't know any one that has tried this.

Also, all the 6.10.x versions and many of the 6.6.x (the latter ones) have also bent the RS as it applies to GPUs because GPU tasks are run in strict FIFO order ... I talk about this elsewhere and am too tired to go deeper unless you need it ... if so, ask and I will pcik up tomorrow when and if I can ...

I have to admit, I never considered that BOINC RS could be a messy process, much like making hot dogs. Geez, folks, it sounds almost embarrassing. Also, thanks for the advice on versions. That is a question on another thread that needs a reply.

---

(Click for detailed stats)

I have to admit, I never considered that BOINC RS could be a messy process, much like making hot dogs. Geez, folks, it sounds almost embarrassing. Also, thanks for the advice on versions. That is a question on another thread that needs a reply.

There are BOINC papers:

GPU Work Fetch
GPU Sched
Client Sched Version Four
Client Sched

With the first three illustrating the earlier policies and the last showing the the latest information on the current intent to the extent that it is not already obsolete. Sadly there is another paper and I can't find it that talked to the intermixing of CPU plus GPU tasks and how the RS was to be split amongst the two Resources because of the differences in computing capabilities ...

Sadly this is the par we have where it is nearly impossible to find out what the current intent and design goals are because UCB throws these papers together, implements something, makes changes and drifts in new directions and never really goes back and cleans up the rabbit trail ... making sausage is cleaner and likely more fun to watch ...