In review process, one step is to check the real transfer rate. If it's much lower than the naming value, we will require vendor to explain the reason, and will ask vendor to run some manual tests. In cert#828100, v7 reports return value of bw_tcp is 400MBps: <snip> TCP latency using 10.0.0.10: 0.0940 microseconds testing bandwidth to 10.0.0.10... 0.065536 408.99 MB/sec </snip> While vendor reports manual test of bw_tcp returns about 2.1GMBps, and iperf returns 27GBps. For detail, please refer to https://hardware.redhat.com/show.cgi?id=828100#c45 <snip> [root@SA2260-X9DR3-LN4F ~]# bw_tcp -m 65520 -P 8 10.0.0.10 0.065520 2166.37 MB/sec </snip> Also, vendor provides manual step and config info in https://hardware.redhat.com/show.cgi?id=828100#c47 <snip> I did the following steps: - set CONNECTED_MODE=yes and MTU=65520 in /etc/sysconfig/network-scripts/ifcfg-ib0 (for both server and test system) - set the governor to performance in /etc/sysconfig/cpuspeed - bound the process qib_cq to a specific CPU core with 'taskset -pc 3 $(pidof qib_cq)' on both server and client </snip> Wondering could the process of network test be improved to reflect max real transfer rate?
I want to add some remarks: - To get a result near the maximum throughput it's best to have eight (8) parallel streams. I have also tested with lower and higher values but it figured out that the configuration based on eight streams shows the best performance. - The taskset command is most useful when the defined CPU core belongs to the CPU that is providing the PCIe lanes for the Infiniband adapter (in my case QLE7340). Best regards Marcus Wiedemann
*** Bug 882088 has been marked as a duplicate of this bug. ***
Created attachment 733253 [details] network test patch to apply bandwidth goal to tcp bandwidth testing The patch changes the bandwidth portion of the TCP testing to try different parallelism settings: 2, 4, and 8 in and attempt to verify transmission at 80% of the interface speed. If this goal is not met, warning messages are logged. The test passes so long as bw_tcp does not produce errors.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1139.html