s...@home has already studied this. Most errors come from relatively few hosts. Most jobs are done by hosts that NEVER have errors. Adaptive replication identifies these hosts and periodically checks them in case they go bad. Always using replication with reliable hosts is a waste of time and carbon emissions. Other projects report the same thing.
Any unreplicated computing is not 100% reliable. (nor is replicated computing, but it's much closer). But all computational science applications that I know of are unaffected by small error rates. For example, in s...@home, a few false positives don't matter because they won't be matched by companion signals. A few false negatives don't matter because we cover the sky many times (actually, they don't matter anyway). Genetic algorithms tolerate errors. And so on. Mathematical searches want an error rate as close to zero as possible. They should use 2X replication. -- David Raistmer wrote: > To estimate confidence level for result returned under adaptive replication > and vitality of this approach I propose such experiment: > Run on SETI main (cause we talk about statistical approach small user/host > base and much lower device diversity of SETI beta will not fit) under > adaptive replication for some time, enough to determine "trusted" hosts and > go to replication of 1 for them. > But keep track of all single replicated tasks. > Then reissue all single replicated tasks again (and keep in mind, that all > their results alrady in science databese) and do standart validation between > previously returned (and still keeped - it's required for this experiment) > result and newly returned one. % of failed initially returned results will > show experimentally if adaptive replication is viable idea or ... not :) > > Such experiment also (if we will keep results we eventually can avoid master > database damage so it can be done) will show how much performance benefit we > really can get (what will be % of "trusted" hosts and so on). > One real complication - it requires to store recived results for pretty long > time - big load on current SETI infrastructure possible. > > wbr > Raistmer > > _______________________________________________ > 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.
