Adaptive replication is substantially better than a replication of 1, which
is what many projects, inappropriately, choose. It should be an option,
not a requirement.
How often the host gets a wingmate depends on two things.
1) The failure rate of that host.
2) The failure rate of all hosts.
If the individual host has a very low failure rate, it will get a wingmate
very rarely if it is the first host to pick up the task. If the failure
rate of the rest of the hosts is fairly high, even a very reliable host
will often end up getting the second task from a WU.
For example, a single host has had 0% failure rate. That means that it has
a very close to 0 chance of getting a wingmate if it is first. However,
all machines together have a 10% failure rate. So, about 10% of the time
it will be the second host to get a task.
Yes, there is some chance of allowing a bogus result into the DB. However,
with replication set to 1 task for most projects, there is NO chance of
determining if any result is correct. Machines could be returning 100%
bogus results and the project would NEVER know.
jm7
Raistmer
<[email protected]
> To
Sent by: "David Anderson"
<boinc_dev-bounce <[email protected]>,
[email protected] <[email protected]>
u> cc
BOINC Developers Mailing List
<[email protected]>
11/09/2009 12:22 Subject
PM Re: [boinc_dev] [boinc_projects]
new credit design
Well, OK.
Any probability calculations for accepting invalid result in replication of
2 versus adaptive replication available already?
I feel that adaptive replication will increase chances to get invalid
result
passed inside database by orders of magnitude.
It can make BOINC as whole untrusted system, not single participant's PC.
Again, even host with absolute clear history can start to produce invalid
results at some point at time.
For example: addition of semi-broken new device to host will not change
host
number so old spotless history will be used until regular check will open
eyes for BOINC. How often you will do such check? If too often - what the
reason to mess with this adaptive replication at all? If pretty rare - many
invalid results can pass validation before BOINC could react on this (what
I
meant calling such mechanism "clumsy" ).
Lack of validation _for each result_ = accepting invalid result in
database.
Changing conditions for adaptive validation = just changing anticipated %
level of such results.
----- Original Message -----
From: "David Anderson" <[email protected]>
To: <[email protected]>
Cc: "BOINC Developers Mailing List" <[email protected]>
Sent: Monday, November 09, 2009 7:56 PM
Subject: Re: [boinc_dev] [boinc_projects] new credit design
> That's pretty much what it does. Have you looked at the code?
> -- David
>
> [email protected] wrote:
>> Adaptive replication should track a machines validation and error
>> history.
>> Machines that have high error rates (and the machine you are describing
>> has
>> a high error rate) will have a very low chance of running without
>> validation. On the other hand machines that never have validation
errors
>> will have a very high chance of running solo.
>>
>> The way I would do it is to store a success fraction per computer (1 -
>> (errors + aborts + invalid)/total tasks). The calculation of whether to
>> actually issue another task after this one would be: (R - (N + 1))*F*C
>> where R is the replication level requested by the project (one based),
>> and
>> N is the replication number of this replication (0 based), and F is the
>> Success Fraction for this project on this computer, and C is some
>> constant
>> to prevent computers have regular errors from ever running solo. Since
>> (R
>> - (N + 1)) is 0 for the last requested replicant, no others will be
>> issued
>> unless there is an error or late task. If C is 10, then only tasks that
>> have better than 90% success rate will EVER run solo in a 2 replicant
>> system. C could be a project setting, but it should never be allowed to
>> be
>> set to less than 1. Arguably, 10 is about right.
>>
> _______________________________________________
> 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.
