On Sat, Jun 23, 2012 at 3:22 AM, Stan Hoeppner <s...@hardwarefreak.com> wrote: > On 6/22/2012 5:45 AM, Muhammad Yousuf Khan wrote: > >> [ ID] Interval Transfer Bandwidth >> [ 5] 0.0-10.0 sec 744 MBytes 624 Mbits/sec >> [ 4] 0.0-10.0 sec 876 MBytes 734 Mbits/sec > >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.0-10.0 sec 744 MBytes 623 Mbits/sec >> [ 4] 0.0-10.0 sec 876 MBytes 735 Mbits/sec > > This shows sustained short duration transfer rates of 78MB/s and 91MB/s. > That's not bad, but can be higher. With good NICs, proper TCP tuning, > and jumbo frames, you should be able to hit a theoretical peak of around > 117MB/s, or 936Mb/s. That's about the limit after all the protocol > overhead. And this assumes your PCI/e bus, mobo chipset, and host CPU > are up to the task. > > These test numbers are a bit meaningless in real world use however, as > most of your iSCSI/CIFS/etc traffic will comprise concurrent small IOs, > transactional in nature, as is the case with the vast majority of server > workloads. > > So instead concentrating on your raw point-to-point GbE bandwidth, you > need to concentrate on the IO latency of your iSCSI and virtualization > servers. Maximizing the random IO performance of these systems will do > far more for overall network performance than spending countless hours > trying to maximize point-to-point GbE throughput. > > One of the few applications requiring long duration throughput is
agreed, KVM backup is is one of them. i am facing this problem most often so as a workaround i need to backup all the VMs locally and then i have to scp them to other network storage. > network based backup. And even in this case you're not streaming large > files, but typically many small files. So again, system latency is a > bigger factor than throughput. > > And in the event you do find yourself transferring vary large files on a > regular basis, and need max throughput, it's most often much easier to > attain that throughput using LACP with two NICs than to spend days/weeks > attempting to maximize the performance of a single NIC. > > -- > Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagwvfmnvpd80sa8j2jlm1gdk48jkan--v9cw0agstboqd6x...@mail.gmail.com
