Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 06/16/2013 11:39 AM, Adam Goryachev wrote: > On 16/06/13 18:47, Luca Fornasari wrote: >> On Sun, Jun 16, 2013 at 6:44 AM, cesar <brain at click.com.py >> <mailto:brain at click.com.py>> wrote: >> >> And about DRBD over a direct connection in mode round robin, can >> you give me >> links or comments about this case? (This is very important for me >> because I >> will lose connection speed if I change of balance-rr to >> active-backup). >> >> >> https://www.kernel.org/doc/Documentation/networking/bonding.txt >> balance-rr: This mode is the only mode that will permit a single >> TCP/IP connection to stripe traffic across multiple >> interfaces. It is therefore the only mode that will allow a >> single TCP/IP stream to utilize more than one interface's >> worth of throughput. This comes at a cost, however: the >> striping generally results in peer systems receiving packets out >> of order, causing TCP/IP's congestion control system to kick >> in, often by retransmitting segments. >> The problem is you have out of order packets and it doesn't help if >> you start to play around with net.ipv4.tcp_reordering sysctl parameter >> because there will always be a chance to have out of order packets. >> Ordered packets are indeed fundamental to DRBD. >> In DRBD world the bonding driver is used to achieve HA using >> active/backup or 802.3ad. Neither of which will boost your performance >> (802.3ad can improve performance if and only if you have a great >> number of TCP connections but that's not the case with your DRBD >> scenario). >> > Hi, > > It was my understanding that this was only the case if switches were > involved, and especially different switches. When you have 2 (or more > ports) on one machine connected via crossover cables to another server > with an equal number of ports (obviously), and you configure both sides > with RR, then all packets should arrive in order. > > Since packet 1 is sent on eth0, and packet 2 on eth1 from server 1 > Server 2 will receive packet 1 on eth0 and packet 2 on eth1 in the same > order. > > If you had switch1 between the two machines on eth0, and switch2 between > the machines on eth1, then it is very possible the switch will introduce > different amounts of delay, therefore causing out of order packets. > > At least, this was my understanding after some recent detailed > reading/research into these matters. If this is still wrong, even for a > set of direct cross over connections, please educate both me and the OP. > > Regards, > Adam Having identical hardware in back-to-back config maximizes the chance that the packets will arrive in order, but it does not guarantee it. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?