On Wed, Apr 21, 2021 at 04:21:54PM +0800, Yunsheng Lin wrote:

I tried using below shell to simulate your testcase:

#!/bin/sh

for((i=0; i<20; i++)) do taskset -c 0-31 netperf -t TCP_STREAM -H 192.168.100.2 -l 30 -- -m 1048576 done

And I got a quite stable result: 9413~9416 (10^6bits/sec) for 10G netdev.

Perhaps try it without the taskset, in my test, there was only one connection.

...

https://github.com/mkubecek/nperf

It is still raw and a lot of features are missing but it can be already used for multithreaded TCP_STREAM and TCP_RR tests. In particular, the output above was with

nperf -H 172.17.1.1 -l 30 -i 20 --exact -t TCP_STREAM -M 1

I tried your nperf too, unfortunately it does not seem to work on my system(arm64), which exits very quickly and output the blow result:

root@(none):/home# nperf -H 192.168.100.2 -l 30 -i 20 --exact -t TCP_STREAM -M 1 server: 192.168.100.2, port 12543 iterations: 20, threads: 1, test length: 30 test: TCP_STREAM, message size: 1048576

1 4.0 B/s, avg 4.0 B/s, mdev 0.0 B/s ( 0.0%) [...]

Did you start nperfd on the other side? (It plays a role similar to netserver for netperf.) Few days ago I noticed that there is something wrong with error handling in case of failed connection but didn't get to fixing it yet. I'll try running some tests also on other architectures, including arm64 and s390x (to catch potential endinanity issues). Michal