Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 556804

Summary: cman sets token_retransmits_before_loss_const wrongly
Product: Red Hat Enterprise Linux 5 Reporter: Christine Caulfield <ccaulfie>
Component: cmanAssignee: Christine Caulfield <ccaulfie>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: cluster-maint, iannis
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-21 23:26:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christine Caulfield 2010-01-19 13:34:36 UTC 
Description of problem:

cman currently sets the corosync parameter totem.token_retransmits_before_loss_const to 20. The reasons for this seem to be lost in the mists of time, but recent testing of openais timeouts suggest that it is unhelpful at best, and may actually impede operation of larger clusters

With the normal cman defaults I could get a 32 node cluster up and running with no trouble. But reducing the token timeout much below that would cause failures. By removing this rogue value from cman and letting corosync calculate it, the token value could be reduced quite significantly and keep a stable cluster.

That might not sound very useful in itself (though it always handy to reduce node failure detection times), but it could have implications for running normally configured clusters on busy LANs or systems. So I recommend we remove this configuration value.
Comment 1 Lon Hohberger 2011-02-15 21:16:58 UTC 
So, Steve thinks this may be related to bug 623176.

What did you mean by "reducing token timeout much below that" -- below what, 10,000ms ?
Comment 2 Lon Hohberger 2011-03-21 23:26:20 UTC 

*** This bug has been marked as a duplicate of bug 623176 ***