Josef:
I don't understand the reasoning here.
If there aren't enough jobs to satisfy both the CPU and GPU requests,
isn't it better to send jobs only for GPU?

Is there a scenario where the current policy results in
less throughput (i.e. less credit) than some other policy?

-- David

On 21-Mar-2012 9:09 PM, Josef W. Segur wrote:
> The current method of choosing which app version is "best" for a given task 
> on a
> host is based on the highest projected flops. It seems that quickest projected
> turnaround would be better for the project and make more sense to users. If 
> the
> work request is for a single resource the choice does not differ, of course, 
> but
> for two or more resources it may.
>
> Suppose a host asks for 120000 seconds of CPU work and 20000 seconds of NVIDIA
> GPU work. If the host has a quad-core CPU and a single GPU that's roughly 
> 30000
> seconds for each CPU. IOW, the host is saying that it would likely start a CPU
> task 10000 seconds before a GPU task. That's only part of the turnaround time,
> but perhaps enough to base the choice on. That is, the first task would go to
> CPU and its estimated time be subtracted from the CPU time request as always.
> Then for the next task the balance might have shifted so the GPU gets that 
> one.
>
> Particularly when there's some limitation on the number of tasks available, 
> this
> method would tend to keep all the host's resources useful to the project. With
> the current algorithm I've seen many complaints on SETI@home forums about
> getting GPU work when the CPUs are about to (or have actually) run dry, and 
> some
> for the opposite condition. It's basically that when the requests for both 
> types
> are more than what's currently available, all assigned tasks go to one 
> resource.
> The same resource is chosen on subsequent requests unless the requested amount
> of time for that resource is reached.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to