No consensus yet => random result
23 Jun 2006 8:43:59 UTC
Topic 191435
(moderation:
When the validator decides "Checked, but no consensus yet", it would be necessary to increase the quorum for that work unit.
Currently with two not matching results, caused by 2 different clients, the third one might be from this or from that client and thus can make this or that result valid.
The result might statistically more likely be correct than incorrect but there is still quite a good chance that it is the other way.
This has not been so much a problem when the quorum was 3, but with a quorum of 2 it would be more secure to increase the quorum in this situation.
No consensus yet => random result
)
You make a very good point - which needs to be addressed quickly. If one of the patched apps that Akos is releasing happens to return invalid results, it only needs two of the extended quorum of three to be running that patch, to have the wrong result validated. The correct solution is, I think, to have a small group of beta testers rather than a much larger public testing scheme. This means that the chance of more than 1 out of three using the patched app should be vanishingly small.
Thanks for bringing this up.
Cheers,
Gary.
The redundancy factor on both
)
The redundancy factor on both short and long S5 results is:
max # of error/total/success results 20, 20, 20
This means that if two out of the quorum of three return an erroneous result, it'll be sent out again to two further hosts. Even if they return the result as erroneous, it's sent out to two further hosts. If need be all the way up to 20 hosts.
What are the chances all of those hosts will return the result as an error? The odds are even better on the quorum of two.
Seti Enhanced is using 5, 10, 5 as redundancy on a quorum of 3. That's more prone to problems than the higher numbers here at Einstein.
The problem is that the two
)
The problem is that the two patched apps in the quorum would return results that are wrong but would be the same as each other and would therefore "validate". unfortunately, the only correct result would be "invalidated" by the two bad results agreeing with each other.
Of course, not really knowing how things work at this low level, i am assuming that Akos' 0004 patch produces the same "bad" result on different computers rather than some result that is randomly and recognisably wrong. The fact that the validator has to call for a third result to break the deadlock means that there is really no way of knowing in advance that a "bad" result has been produced :).
Cheers,
Gary.