Marc Grimme wrote: > On Wednesday 30 July 2008 20:52:07 John R Pierce wrote: > > Mag Gam wrote: > > >> 70-80Mb/sec. > > > > > > MB, sorry :-) > > > > thats on the order of 700-800Mbit/sec, which is quite good for a single > > session on GigE. as others have said, the sort of bonding you're doing > > doesn't speed up single transfers, instead it helps with multiple > > concurrent sessions. > > I would not agree that if you are using round-robin (mode 0) bonding that it > does not scale with one session. I would say it should or must scale: > > from bonding.txt: <snip> > > That means it could if we forget about out of order delivery. > > What I see in a project where we have bonded four nics together with rr is > that the way out is "evenly" loaded over the four nics (although we are > communicating with only two hosts). But the way back is still the problem. > Cause all packets arrive at only one nic. Again this is explained by > bonding.txt: What you are forgetting is the two-way communication between client and server during a file transfer. With NFS using 4k IOs over TCP (with NFSv3 NFSv4) there are acks that need to come back within the window (64K or every 18 IOs) and IO will pause for them to catch up, and even if things are running smoothly and IO doesn't need to pause for acks, there is the network latency of data travelling back and forth that needs to be taken into consideration. With network IO it's not the bandwidth that kills you it's the latency. Network bandwidth becomes important when the number of clients gets large, say 100 or 1000 clients. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos