I certainly agree, and even were it a perfect method of finding problem
hosts the best method of minimizing their damage to the project is
uncertain. Your inputs along that line have seemed very good to me.
--
Joe
On 27 May 2010 at 20:06, [email protected] wrote:
> Run time only picks up some of the possible problems. It may be a help,
> but not the entire solution.
>
> jm7
>
>On 27 May 2010 at 13:06, I wrote:
>
>> The client-side detection of a sequence of tasks completing in suspiciously
>> short times I suggested earlier could probably be done server-side instead.
>> The average and variance of elapsed time/rsc_fpops_est is maintained for each
>> app_version on a host, and could be used to judge whether an elapsed time is
>> suspiciously small or large.
>>
>> The consecutive_valid count also maintained for each app_version is the
>> replacement for the deprecated error_rate. If the count is less than 10 the
>> app_version on that host is considered unreliable and not eligible for
>> unreplicated work, etc. That count is incremented for each validation against
>> another host's result, cleared for results which fail validation and
>> unsuccessful results (both error and deadline timeout). A single suspicious
>> elapsed time shouldn't clear the count, but perhaps a reduction sequence
>> would
>> make sense.
_______________________________________________
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.
