Most of the computation errors that computers make are because they are
overheating or grossly overclocked. These tend to produce random errors,
and it is these that the redundancy will weed out as the odds of two random
answers of 128 bits being the same is a very good approximation of 0. One
in 10^36 about. Redundancy also weeds out cheats. Because of this, all
projects that do not have a quick calculation from the answer back to the
original question should implement redundancy.
Catching something like the Intel bug of a few years ago would require
running a short task exactly once in the lifetime of the installation of
BOINC on a particular hardware platform. It does NOT require wasting a
collective million hours of CPU time every week doing gold plated
benchmarks.
One suggestion is to use a reputation based method. If validation fails
enough times on your machine, your reputation degrades, and you get to do a
reference task, and if you fail that, you may have your quota instantly
dropped to 1. If your quota is 1 and you are doing a reference task, all
you get is reference tasks until your computer starts returning valid
results. If a machine always generate valid results, then you might reduce
the redundancy for that machine to something like 1 in 5 so that it would
be allowed to solo 4 out of 5 tasks.
Most machines work almost all of the time. There are a few machines that
fail always.
jm7
"Paul D. Buck"
<p.d.b...@comcast
.net> To
"Lynn W. Taylor" <[email protected]>
09/28/2009 02:42 cc
PM [email protected], BOINC
Developers Mailing List
<[email protected]>
Subject
Re: [boinc_dev] [boinc_alpha] Card
Gflops in BOINC 6.10
On Sep 28, 2009, at 11:13 AM, Lynn W. Taylor wrote:
> The benchmark affects the estimated run time, and the amount of work
> downloaded. It affects credit, and credit is "fun" but it's not
> science.
Then you are also guilty of not reading the proposal. I have always
said that while running calibration tasks that the same compensation
would be paid for a calibration task as for any other task. In fact,
I said that it could qualify for a bonus to encourage participation in
the system. In that we have resistance as you and John express
because you don't seem interested in any attempt to improve the
operation of the system as a whole.
> As you correctly said, it will measure something about the quality
> of the network.
>
> What John said (and you apparently didn't read) is that the science
> application produces a result, and that result is either valid (the
> calculations were performed correctly) or they're wrong (the result
> of the calculations is incorrect and useless).
Validation is not a magic wand and only usually means that two (or
more) computers returned the same answer not that the answer is in
fact correct. With more and more projects move to single system
answers this means that this leg of redundancy is disappearing. I
grant that there are some cases where there can be an absolute
validation, but I am suspicious of some of the claims of infallibility
because history says that thinking that computer generated results are
correct results. Another case in point is the F-Div bug where two
Intel processors would return identical wrong results ... how many
other bugs like that exist, we don't know ... but assume that they
don't exist because we have not seen them ... of course we are also
not looking ... and working very hard to never look ...
> It's a two way street, Paul.
Yes, it should be. Sadly what usually happens is that people don't
read what I write but skim it and then reject it in favor of not doing
anything or on grounds that are spurious.
> If you have a technical argument, present it (and only the technical
> argument). When you accuse people of not reading, or not adopting
> your ideas because they're your ideas, that becomes a self-
> fulfilling prophesy.
If you have suggestions to improve one of my ideas you will find that
I am always happy to include those into the proposal. And I only
accuse people of not reading when it is clearly obvious that they are
not reading. If they are objecting on the grounds that I do x when I
clearly have stated that we will not do x ... or that I don't have
feature y when I clearly defined that I have feature y ...
So, if I am restricted to only presenting technical ideas and
arguments to those technical ideas, why can you do otherwise?
As to the other point, well, it is not that they are just my ideas ...
UCB pretty much rejects all ideas that do not originate at UCB ... or,
it is proposed as a UCB idea a year or two after it was proposed ...
_______________________________________________
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.
