My first thought is that there needs to be some sort of initial quota that should probably be lower than 100 -- someone might try BOINC but uninstall right away, or not like how it makes their computer run 100% or who knows what -- and uninstalling shouldn't abandon a bunch of work.
... and there should be an upper bound that prevents one host from grabbing more than their fair share -- maybe limit any one host to 20% of the work split in any given hour? If successful results raised the quota quickly (factor of 4), and lowered it relatively slowly (factor of 2) then a machine returning one good work unit for every 2 bad ones wouldn't be penalized, only the machine returning consistently bad work? I'm sure there is a more elegant solution. -- Lynn On 5/24/2010 12:03 PM, David Anderson wrote: > The BOINC scheduler has a mechanism called "host punishment" > designed to deal with hosts that request an infinite sequence of jobs, > and either error out on them or never return them. > > It works like this: there's a project parameter called "daily result quota", > say 100. Every host starts off with this quota. > If it returns an error or times out, the quota is decremented down to, > but not below, 1. If it returns a valid result, the quota is doubled. > The idea is that faulty hosts are given 1 job per day > to see if they've been fixed. > > Recently this mechanism was changed from per-project to per-app-version, > the idea being that a host might be erroring out on a GPU version > but not the CPU version. > > However, the basic mechanism is somewhat flawed: > > 1) What if a fast host can do more than 100 jobs a day? > We could increase the default quota, but that would let bad hosts > trash that many more jobs. > > 2) It takes too long for a fixed host to ramp up its quota. > > The bottom line: as long as a host is sending correct results, > it shouldn't have a daily quota at all. > > --------- > > If anyone has ideas for how to change the host punishment mechanism, > please let me know. > I'll think about it and post a proposal at some point. > > -- 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. > _______________________________________________ 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.
