On Thu, 2010-01-28 at 15:55 -0700, hj lee wrote: > Hi, > > I am using corosync-1.1.2 on CentOS 5.3. In corosync.conf man page, I > read "The rrp_problem_count_threshold * rrp_token_expired_timeout > should be at least 50 milliseconds less then the token timeout". I > think the "less than" should be changed to "more than". Or both less > than or more than may be OK. > > If the rrp_problem_count_threshold * rrp_token_expired_timeout is less > than the token timeout, then the link become faulty before token > timeout. This disables the link before trying GATHER mode. Is it the > intended design? Shouldn't the totem try GATHER mode before disabling > a link by faulty? > > Is this (making a link faulty) a part of RRP protocol? >
It has been several years since I originally implemented RRP, and unfortunately don't have an immediate answer to your question regarding timing constraints. I believe the constraint is there to ensure that the last valid token is delivered before marking a link faulty. Unfortunately I don't recall the exact reasoning for this constraint. I'll have to do some research to gather an answer. Marking a link faulty is part of the specification, which can be read here: http://rcsc.de/pdf/icdcs02.pdf > Thanks > hj > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
