A few more thoughts. For the purpose of reliability, a host should be considered to have failed at a task if it is aborted, generates a runtime error, reaches the deadline without being returned, or fails to validate. If the project is down at the time of the deadline, the deadline should be extended to be the time that the project comes back up + 24 hours, or the time between connections specified by the server. This avoids having reliable clients dinged because of a server problem.
Perhaps reliability should be based on a reducing average with a 2 week half life. Yes, there can be some lag in the calculation because tasks can be validated much later than the submission. However, a host that fails to validate most of its tasks cannot be considered to be reliable. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of McLeod, John Sent: Thursday, August 30, 2012 10:55 PM To: David Anderson; [email protected] Subject: Re: [boinc_dev] resent WUs added to the end of the WU queue Give every host a rating of 0 to 1 on reliability. Hosts that fail everything get a 0. Hosts that return everything correctly on time get a 1. Reliability should have a "recent" component to it. If I had a bad configuration and was failing everything two months ago, and am getting everything right now, the problem 2 months ago should have little effect on now. The older the task is, the higher the probability of handing it out to a lower reliability client should be (to avoid starvation). However, a very untrusted client should still have a much lower chance of getting the task. If the client has the required files for locality, it should get a higher chance. If you have special tasks on hand, and a host connects, give the special tasks if a random number is < f(reliability, locality, age of task, time from committing a task till deadline). f(double reliability, bool localityl, double age, double deadline) might look something like: reliability ^2 * (locality ? 1.0 : 0.5) + age / deadline; If the task is new, it is all about reliability and locality. As the task ages, it becomes all about age. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Anderson Sent: Thursday, August 30, 2012 3:40 PM To: [email protected] Subject: Re: [boinc_dev] resent WUs added to the end of the WU queue In the shared-mem job cache framework, server-side scheduling has 2 parts: - the order on which jobs are put in the cache - the policy for selecting jobs from cache to send to a particular host. This part of BOINC has evolved in a piecemeal fashion, and is due for a remodel. Plus it needs to support optimized batch completion, which is something we've talked about but not done anything. I created a wiki page with some notes on this: http://boinc.berkeley.edu/trac/wiki/JobPrioritization Comments/ideas welcome. -- David On 29-Aug-2012 2:19 PM, Travis Desell wrote: > See: > > http://volunteer.cs.und.edu/subset_sum/forum_thread.php?id=47 > > Is there any kind of project setting which will have resent WUs added to the > beginning of the WU queue (so they are sent out quicker for validation)? > > thanks, > > --Travis > > --------------------------------------------------------------------------- > Travis Desell, Assistant Professor University of North Dakota - Dept. of > Computer Science [email protected] - cell: 518-867-1054 Streibel Hall > Room 220 - office: 701-777-3477 3950 Campus Road Stop 9015 Grand Forks, North > Dakota 52802-9015 > > Homepage ( http://people.cs.und.edu/~tdesell/ ) MilkyWay@Home ( > http://milkyway.cs.rpi.edu/ ) DNA@Home ( http://volunteer.cs.und.edu/dna ) > Worldwide Computing Laboratory ( http://wcl.cs.rpi.edu/ ) > ---------------------------------------------------------------------------- > > _______________________________________________ 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. _______________________________________________ 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.
