John: I updated the proposal: http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen Please review. -- David
On 28-Oct-2010 11:56 AM, [email protected] wrote: > 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.
