A little lesson of iPerf testing network speed

Recently, there is a small lesson in using iPerf, which can be used as a warning for simple records.

Last week, Douzi upgraded its WAN broadband from 20m to 1G. The settings of optical fiber, SPF, switch port, VLAN, iBGP and so on are all in strict accordance with the requirements of ISP. After the final upgrade is completed, Douzi does a network speed test on iPerf.

In my opinion, iperf testing should be simple, running ipferf.exe-s snooping on one side of the machine and iperf.exe-c IPaddress on the other.

The results of the test are shown below. As soon as the beans take a look, Nima, why is the bandwidth only 100m? Given the unreliable history of our ISP, my first reaction was that ISP was fooling around again. So angrily contact the boss and each other's account manager,% ¥#! # ¥@, after a complaint, the other party said that an engineer would be arranged to test the speed.

After 2 days, the test results came out, and the network speed was no problem. Kick the ball back to me. Beans scratch the scalp, what on earth is wrong? After research, finally found that the Internet speed is really no problem, the problem is my testing method!

IPerf can perform multi-thread concurrency testing. By default, only one thread is executed, but when the bandwidth is very large, it can not reach the maximum bandwidth limit at all, which causes iPerf to give a wrong bandwidth value. When I run dozens of threads for stress testing at the same time, the real upper limit is revealed.

For example, 25 concurrent tests on the same server show a speed of about 930m, which is the real speed value.