> The following 3 mechanisms work together: > > 1) adaptive replication (to reject wrong results with high probability) > Possibly with an added app-specific consistency check as John suggests. > Hopefully they'll become the defaults. > > - DPA >
Truly hope this doesn't become default. Adaptive replication completely ignore random events. It's just too clumsy to react on such events. For example, I have GPU that after many hours of work can start to produce overflows on SETI. No single error reported in stderr, it just starts to process junk and to find many signals there. After reboot it again behave as good device. What will be in science database from such devices w/o redundancy at least of 2 ? All that junk will go directly into database cause host returns also many results from other devices so it has enough time to gain server trust (just to be rude deceived ). This is a situation where _many_ (!) invalid results can go into database w/o validation. Of course there are invalid results from borderline OCed systems, 1-2 invalids per week quite possible. If you will make trust gain conditions too hard, it will not bring much performance benefits while will have all the same defects. Because even totally trusted host can start to produce invalid results at some point of time (trivial - dust in fan ;) )(sanity check will not help at all cause if you process by correct rules but wrong data there are very small chances it can be noticed w/o complete comparison with another returned result). And if you will make trust gain conditions easy projects' databases will overflowed with invalid results. Cause in my case for example to generate invalid overflow it takes ~26 seconds while to process task it takes ~100 minutes. Hope you get any impressions what will be if some high-end GPU will go mad.... (my is low end of course). And again, to say "this overflow is not valid one" you need to check it against another result, overflow by itself (-9) completely legal on SETI MB. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
