It seems that BOINC cannot provide such functionality by design. BOINC scheduling is "one host at a time", so once there is a job request it will be satisfied regardless the state of other hosts. Of course there are tricks like homog. redundancy and alike, which break this abstraction and refuse to send something to a host already having results of that wu, but conceptually the scheduling process does not attempt to match "better host" to a job. This probably can be changed, but it would be difficult, I think.
If you ask me, I'd use Condor in that case - this one does EXACTLY what you want, but has its own problems... On Sun, Apr 26, 2009 at 1:14 PM, Paul D. Buck <[email protected]> wrote: > > On Apr 26, 2009, at 2:51 AM, Alan Sun wrote: > > > Suppose this situation: > > > > I have 5 client machines in BOINC system and they all point to 1 > > project. We > > can named them as "A", "B", "C", "D" and "E". > > > > The performance of A and B are much lower than C, D and E. For the > > whole > > system, I submit the same jobs. Now, I want the system running like > > this: > > > > If all of client machines are idle, the jobs will be sent to C, D > > and E > > firstly; if C, D and E are all busy, the jobs will be sent to A and > > B. In a > > word, the work fetch priority of C, D and E is higher than A and B. > > > > For the client machines performance evaluation, the information in > > "host" > > table of database may be useful. > > > > How can I do this? > > > > Thanks! > > From the project perspective you use the concept of the reliable > systems. For example, on GPU Grid my i7 machine returns tasks on the > average of one every 6 hours. Tasks generally live on my system for > less than 12 hours ... also I have a low failure rate ... these two > factors combine to make that system highly reliable. > > If, and only if I send back an error, I get penalized and if I send > back enough errors I drop off the list for consideration of highly > reliable. As I return good work I gain back the project trust and > become reliable again. > > Also look at: > > http://boinc.berkeley.edu/trac/wiki/LowLatency > > http://boinc.berkeley.edu/trac/wiki/RpcPolicy > > http://boinc.berkeley.edu/trac/wiki/AdaptiveReplication > > _______________________________________________ > 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. > _______________________________________________ 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.
