Hmm. I must be particularly dense today - I didn't notice what you describe after a short review of the code in drivers/net/bonding.c. That code appears to use each bonded channel in order [round robin as described in Documentation/network/bonding.txt]. Is that the right place to look or is there some other information [online or otherwise] that describes the algorithm used in channel bonding? I am also curious why it is "better" to send packets out of order [and may cause congestion]. What problems does that algorithm solve that are worse than channel congestion and 1/10th the expected performance? Re: setting the TCP window size. I'm using the defaults [unless the application happens to set it - I will check]. For the "how to set the TCP window size", I assume you are referring to using "route" to do so (e.g., route ... window W). I noticed the route (8) man page says this is "typically used on AX.25 networks and drivers unable to handle back to back frames". Is there something inherent in the Ethernet interface that would require this? Thanks. --Mark H Johnson <mailto:Mark_H_Johnson@raytheon.com> "Andi Kleen" <ak@suse.de> To: Mark H Johnson/RTS/Raytheon/US@RTS cc: ak@suse.de, linux-net@vger.kernel.org 08/25/00 Subject: Re: Performance with ethernet channel bonding 06:11 PM > - Would the channel bonding code send the packets out of order [to cause > the problem you describe]? Yes it does, it is inherent in the algorithm it uses. If you don't believe me just send a stream of UDP packets with a sequence number and plot the result. > - I thought about packet drops as well, perhaps an SMP race condition? > We've noted that the error counts from ifconfig don't increment until a > slight increase at the end of the run, so it's not counting the problems if > they do occur. [had 22 overruns recorded after >1.5M packets transmitted & > received without any overruns! Overruns on one machine only, not both.] I doubt it is the problem. You of course made the TCP window big enough ? -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
