On Mon, Dec 13, 2010 at 6:43 PM, Daniel Doubleday <daniel.double...@gmx.net>wrote:
> Oh - well but I see that the coordinator is actually using its own score > for ordering. I was only concerned that dropped messages are ignored when > calculating latencies but that seems to be the case for local or remote > responses. And even than I guess you can assume that enough slow messages > arrive to destroy the score. > That's odd, since it should only be tracking READ_RESPONSE messages... I'm not sure how a node would send one to itself. Maybe I misunderstand but that would not really lead to less load right. I > don't think that inconsistency / read repairs are the problem which leads to > high io load but the digest requests. Turning off read repair would also > lead to inconsistent reads which invalidates the whole point of quorum reads > (at least in 0.6. I think rr probability has no effect in strong reads in > 0.7) . Again assuming I am not misinterpreting the code. > Ah, I see what you want to do: take a chance that you pick the two replicas (at RF=3, at least) that should agree, and only send the last checksum request if you lose (at the price of latency.) -Brandon
