<div>One could use the ...I'm thinking of the extra-big-packet size in IP6. But if you have small numbers of large datasets, you could increase your perceived bandwidth with two NICs and larger packets, maybe by using some protocol other than TCP?
</div>
<div>Thanks,</div>
<div>Peter<br><br></div>
<div class="gmail_quote">On Jan 8, 2008 1:29 PM, Patrick Geoffray <<a href="mailto:patrick@myri.com">patrick@myri.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Peter St. John wrote:<br>> I don't get it? I would have thought that if a large package were split<br>> between two NICs with two cables, then assuming the buffering and<br>> recombination at each end to be faster than the transmission, then the
<br>> transmission would be faster than over a single cable? You don't mean that<br><br></div>The problem is ordering of packets and TCP. When you send a single TCP<br>stream over two (or more) paths, then some packets will arrive
<br>out-of-order at the destination. TCP really does not like out-of-order<br>packets and performance takes a (big) hit.<br><br>That's why most channel bonding mechanisms balance multiple streams over<br>multiple NICs and send each stream on a single NIC. Other protocols than
<br>TCP may not have this problem if they don't require strict ordering for<br>performance.<br><font color="#888888"><br>Patrick<br></font></blockquote></div><br>