The default should be adaptive replication with a requested number of
replicants of 2. MOST projects have no backward method of generating the
question reliably from the answer. Prime Grid can only tell if a reported
pair of numbers actually divide the proposed prime. If no divisors are
reported, there is no way of telling if the work is correct (false
negative). Prime Grid should be running with replication of 2, but, due to
the perceived waste of the second replicant,, I believe they are not.
jm7
Raistmer
<[email protected]
> To
Sent by: "Raistmer" <[email protected]>,
<boinc_dev-bounce "David Anderson"
[email protected] <[email protected]>, "John
u> Keck" <[email protected]>
cc
BOINC Developers Mailing List
11/08/2009 03:59 <[email protected]>
AM Subject
Re: [boinc_dev] [boinc_projects]
new credit design
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.
_______________________________________________
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.
