It's quite possible to do it without changing the project's operating
mode, analysis of the validator log entries of the change in error_rate
whenever there's an invalid result should be adequate. The code for
those log entries is:
log_messages.printf(MSG_DEBUG,
"[HOST#%d] invalid result; error rate %f->%f\n",
host.id, old_error_rate, host.error_rate
);
I presume that will become slightly more verbose when "error rate and
max jobs/day are maintained for each (host, app version), rather than
for the host as a whole". But parsing for hosts which transition from
the relatively "trusted" 0.05 and below to the "untrusted" 0.1+ seems
relatively easy. One invalid result boosts the error rate by 0.1 unless
the host is already near the 1.0 limit.
That kind of statistical analysis would take some time and add some
work load on project staff, but it's essentially risk free.
--
Joe
On 11 Nov 2009 at 8:16, [email protected] wrote:
> It should be possible to do this without storing the information in the DB.
> Again using s...@h main, just keep track of the "trustedness" of the hosts and
> see what the failure rate is on these hosts some time in the future.
>
> jm7
>
>
>
> Raistmer
> <[email protected]
> > To
> Sent by: <[email protected]>
> <boinc_dev-bounce cc
> [email protected]
> u> Subject
> [boinc_dev] Adaptive replication
> (dis)proving experiment
> 11/10/2009 11:19
> PM
>
>
>
>
>
>
>
>
> 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.
