On Wed, May 26, 2010 at 3:31 PM, Richard Haselgrove <[email protected]> wrote: > In any event, it's pretty clear that it is taken from the canonical result > (validated tasks only), > so it doesn't help us with this BOINC problem.
But is there really a problem? I still don't have an answer to the question what a valid result is. I asked "Is a valid result just those that are not returned immediately with an error, or is it all work after validation? Is it strictly about the work being done, or is it to safe-guard against "wrong-doings with credit?" Now, I am sure it isn't to safe-guard against wrong doing with regards to credit. It doesn't need to be that either. So let me change that and ask: Is a valid result just those that are not returned immediately with an error, or is it all work after validation? Is it strictly about the work being done, or is it to safe-guard against anything going wrong? Earlier, before this thread went astray into a pro-Seti forum, I opted for reliable hosts being the standard, instead of an optional.setting in the project configuration file. David was asking: "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." As I see it that is a reliable host setup. (See http://boinc.berkeley.edu/trac/wiki/ProjectOptions#Scheduler:acceleratingretries for more info). Be it that even on projects where reliable hosts are used, there is still a maximum quota/day set by the project (one such project is eni...@home, with a DQ of 150). I know that the present reliable hosts setup is used to run work in a hurry. Work that has not met the deadline on the hosts it was assigned to and that needs to be done quickly. It could easily be changed to signify whether or not your host is doing good work. Where once it has gained enough trust and is in the reliable hosts group and it runs out of work on a regular basis due to maximum DQ restraints, its DQ limit for that piece of hardware can be increased. If your host starts coughing out errors, it's dropped from the reliable hosts group and limited to the 100 (or less by then) tasks per day, until the error has been fixed and your host is running normal again. But to make sure it is normal, it needs to gain trust again, so it will have to prove by doing enough correct work that it can be in the reliable hosts group again. How much work that is, or for how many days is project settable. -- -- Jord. _______________________________________________ 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.
