Redundancy of 2 catches essentially ALL random errors Given the current
number of computers, it would be more than a millennium before a single
undetected random error was missed - assuming that there were only 128 bits
of output / task.
Your proposal detects no extra random errors. Intel wrote a detector
program for the processor error that they had a decade and a half ago. It
took about 20 seconds to run. Most of these machines are long gone.
Redundancy of 1 is stupid unless the project has a fast method of
verification from result back to the original problem. There are problems
where this is true. Finding the answer is hard, but once the answer has
been found, it is extremely easy to get back to the original problem.
jm7
"Paul D. Buck"
<p.d.b...@comcast
.net> To
Sent by: Raistmer <[email protected]>
<boinc_dev-bounce cc
[email protected] BOINC Developers Mailing List
u> <[email protected]>
Subject
Re: [boinc_dev] [boinc_alpha] Card
10/01/2009 07:32 Gflops in BOINC 6.10
AM
On Oct 1, 2009, at 2:45 AM, Raistmer wrote:
>> The flaw in your comparison is that both with adaptive replication
>> and single task validation more and more projects are going to
>> single task validation...
> Sorry, I especially emphasized REDUNDANCY. Adaptive replication
> doesn't implement this in required degree IMO. Single task vaidation
> too.
> If project go to such measures, it feels it can tolerate with
> decreased level of result validity.
> My words in no way were about adaptive replication or single task
> validation. Let's will not mix these.
My only point was that aside from the sources of error that I have
tried to explain that we will be looking for are not always going to
be detected by the use of HR. If you do use HR with redundancy levels
of 3 and over you may catch some of the errors of which I speak ... I
stress MAY ... at least your chances are higher.
But, AR and single validation knocks out those legs because the effect
is that you are expecting that the computer returning the task will
return a correct answer or one that is so far out of bounds that even
the laxest validator will catch all errors. In some cases on some
projects this MAY be true ... on others it is demonstrably false. And
that is the larger set and more common case ... and the one group I am
addressing.
So, the argument against my idea is that the validator catches all
errors through redundancy ... yet we are whittling away at the scope
and intensity of redundancy all the time... so, ipso facto more errors
are going to not be caught.
_______________________________________________
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.
