Work Fetch Cutoff.
Proposed that:
A project is only eligible for a full work fetch if it has a higher work
fetch priority than all projects that currently have work on the client or
there is no work on the client at all AND the project does not have a
resource share of 0 AND the host is not running all resources of that type
in High Priority.
Full work fetch is the maximum (("extra work" + "connect every X") *
resource fraction, sum (estimated resource idle time before "extra work" +
"connect every X" from now)) for a single resource type. This would be
determined by from a least estimated runtime remaining first.
If a project is not eligible for full work fetch or all of a device type is
running High Priority, the project would be limited to filling sum
(estimated resource idle time before "connect every X" from now) for the
resource type. (Fill the queue to the lowest acceptable point from the
least ineligible project).
This will limit the ability of projects to get perpetually deeper in debt
to the other projects on CPU time. It also side steps the issue where a
GPU has only one project available - the higher priority projects that have
no work available do not count against the work fetch for this project. It
also sidesteps the issue where a project is down for a long time - it won't
have work to run on the system, and will therefore not count against the
other projects filling the queue.
jm7
David Anderson
<[email protected]
ey.edu> To
<[email protected]>
10/27/2010 02:41 cc
PM BOINC Developers Mailing List
<[email protected]>
Subject
Re: [boinc_dev] proposed scheduling
policy changes
On 27-Oct-2010 11:38 AM, [email protected] wrote:
>
> The proposed work fetch policy will also mean that more work will be
> fetched from the projects where the machine is least effective, assuming
> FLOP counting is used to grant credits.
That's a good point.
I'm now leaning towards client-estimated credit
rather than actual credit as a basis.
(Also because of the issues that Richard raised)
-- David
_______________________________________________
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.
