And I strongly emphasize that this has no connection with cherry picking and credits in whole, it's about validity of returned resutls. So all your measures against cheating and cherry picking (both actions have only indirect influence on science done - through participants' minds and attitudes) will not help to improve VALIDITY of results returned with adaptive replication. Why these measures go as single package - ??????.......
----- Original Message ----- From: "Raistmer" <[email protected]> To: "David Anderson" <[email protected]>; "John Keck" <[email protected]> Cc: "BOINC Developers Mailing List" <[email protected]> Sent: Sunday, November 08, 2009 11:44 AM Subject: Re: [boinc_dev] [boinc_projects] new credit design > > >> 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 > [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.
