On Apr 21, 2009, at 8:18 PM, David Anderson wrote: > That's a good thought experiment. > The essence of it is that the current client has 2 laws: > > 1) avoid idle CPUs > 2) once a job has been fetched, try to finish it by its deadline > > and in some cases (like the one you describe) > obeying these laws leads to ignoring resource shares. > > If we weaken the laws we can obey resource shares better; > for example, during the "year of SETI" we could tolerate > idle CPUs for some period (a day? week?) while waiting for > s...@home's server to come back up.
This is one of those "false questions" that proposes to frame the allowable responses to a limited set. The problem is not the two laws as stated and no one is suggesting that they be weakened. Perhaps the laws should be expanded, not contracted. 1) Avoid idle Resources (generalizing) 2) Once a job has been fetched, try to finish it before its deadline 3) Run interesting workload mixes (solves track ticket and improves efficiency, unless it would violate 1 or 2) ---> Deadline tests would "line up" the tasks from a specific project and only if the whole queue would fail to be processed in time would multiple resources be used to process the task stream. Obviously if I have 4 resources and one project all resources would be applied to that project. Same four resources and 10 projects, subject to task availability, two tasks from the same project would not be run at the same time. 4) Honor TSI (switch no task before its time, unless it would violate 1, 2, or 3) The confusion comes in because we have overloaded and confused work fetching concepts and tactics with local resource scheduling tactics. Aside from some data passing involving the actual processing there is no need to couple the concepts or the systems. Or, to put it another way these laws are the laws that guide the resource scheduling which has nothing to do with resource share or work availability on the projects. The laws of work fetch on the other hand are more like: 1) Obtain sufficient work to maintain the "ready queue" (connect interval plus extra work buffer) 2) Maintain a long term balance of work processed by the system that matches Resource Share proportions. 3) Attempt to obtain a mixed proportion of work when attached to multiple projects at all times Another analogy, the two systems should be treated as a linked queue / pool that feeds a processing system ... work fetch obtains a pool of work from the available attached projects and holds it for processing. Sadly, we try to treat it as a monolith and again this gives rise to our problems. If work fetch is doing its job properly there is no need for the resource scheduler to be at all concerned about resource shares. But again, none of this addresses the other issues with resource shares. Migrating to a priority system and allowing "safety" projects more closely maps to the needs and desires of the participants and the same two rules sets above would still be equally applicable and usable. _______________________________________________ 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.
