There are two possible outcomes from a broken host. First is a crash of
some sort. These can be picked up instantly on report. The second is a
validation failure. These cannot be picked up until after validation.
One possibility is to temporarily drop the quota on an undecided validation
where two are returned and they do not match. When validation occurs again
the quota would be increased at that time for the computer that matched.
The first validation attempt generally occurs fairly quickly. A computer
that regularly returns good results would occasionally have its reputation
reduced slightly, but would normally recover quickly when the next task
validated against some other computer. This would mean that we would have
to make the numbers work so that a small number of undecided validations
did not drop the computer out of the trusted category.
This would be faster, and it should not hurt computers that are working too
badly. Yes, if your computer blows through a few thousand tasks and
generates invalid results for them, it could be a while recovering.
However if it is a repeated problem like the CUDA problem at SETI, the
computer should not be trusted for CUDA work until the basic problem is
found and fixed.
jm7
"Lynn W. Taylor"
<[email protected]>
Sent by: To
<boinc_dev-bounce [email protected]
[email protected] cc
u>
Subject
Re: [boinc_dev] host punishment
05/27/2010 10:32 mechanism revisited
PM
Seems to me that the really fast methods of catching a broken host
aren't very good, and the good methods aren't very fast.
Does BOINC need fast?
On 5/27/2010 7:19 PM, Josef W. Segur wrote:
> 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.
_______________________________________________
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.
