One issue about the nsperf test between srv and cli

[Jason Xing]

Hi Neal,

Recently I'm using the nsperf test located in the gtests directory and encounter one issue. When running into the run_test() function, it seems that using 'netperf' command in the srv netns cannot reach to the cli netns because there is one block between srv and srt, crt and cli. One more thing, I can successfully ping and send udp datagram from srv to cli, which really strikes me as odd.

The result says that "establish control: are you sure there is a netserver listening on 192.168.3.100 at port 12865?" and

"establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 192.168.3.100 port 12865 address family AF_INET"

I'm not familar with the netns, so still working on that. If you're available, please help me with that.

Thanks,

Jason

[Neal Cardwell]

Hi Jason,

Thanks for your post. It sounds like there is no netserver process
running, perhaps because the netserver binary was not in the expected
location? Is there a netserver binary, either in ./netserver or
/usr/bin/netserver? Here is the relevant code:

https://github.com/google/bbr/blob/15fd29fce87eb62192fb412263488db108f29e4a/gtests/net/tcp/bbr/nsperf/nsperf.py#L65

def netserver():
if os.path.isfile('./netserver'):
return './netserver'
else:
return '/usr/bin/netserver'

If you are still having issues with the simple nsperf tool included in
the BBR v2alpha distribution, you may want to try the more
full-featured transperf tool we open-sourced in Sep 2019:

https://github.com/google/transperf

best,
neal

> --
> You received this message because you are subscribed to the Google Groups "BBR Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/40ab33f2-85b2-41ab-8e0d-cffbbe17274dn%40googlegroups.com.

[Jason Xing]

在2020年9月10日星期四 UTC+8 下午10:10:29<Neal Cardwell> 写道：

Hi Jason,

Thanks for your post. It sounds like there is no netserver process
running, perhaps because the netserver binary was not in the expected
location? Is there a netserver binary, either in ./netserver or
/usr/bin/netserver? Here is the relevant code:

Thanks for your reply. The problem is that the datagram sent from srv netns cannot reach to the cli netns due to some block between those routes, not that the 'netserver' is not running. If I 'netperf' from srt netns to crt netns, it works and vice versa. I've tested on my various servers and it turns out the results are bad. So it's really weird :(

thansk,

jason

[Jason Xing]

在2020年9月11日星期五 UTC+8 上午10:10:17<Jason Xing> 写道：

在2020年9月10日星期四 UTC+8 下午10:10:29<Neal Cardwell> 写道：

Hi Jason,

Thanks for your post. It sounds like there is no netserver process
running, perhaps because the netserver binary was not in the expected
location? Is there a netserver binary, either in ./netserver or
/usr/bin/netserver? Here is the relevant code:

Thanks for your reply. The problem is that the datagram sent from srv netns cannot reach to the cli netns due to some block between those routes, not that the 'netserver' is not running. If I 'netperf' from srt netns to crt netns, it works and vice versa. I've tested on my various servers and it turns out the results are bad. So it's really weird :(

Here're some other tools test:

1) using 'nc -vuz 192.168.3.100 50100' and it shows that 'Ncat: Connection refused'.

2) using 'echo "hello there" | socat - udp4-datagram:192.168.3.100:8888' and the cli netns can display that string.

3) using 'telnet 192.168.3.100 80' and it only shows 'Trying 192.168.3.100...'.

I tested on different servers. Some have iptables rules, some doesn't have. The result is always the same. Thus I suspect the problem of the behaviour of calling the setup_netem().

thanks,

jason

[Jason Xing]

More info:

I tested between different netns and found that cli netns can send tcp datagrams to srt/mid/crt, that only srv cannot send messages to anyone of them.

Then, I tried:

If I delete this line:

c += 'ip netns exec $h tc qdisc add dev $h.r root fq\n'

then it works, the datagram can be sent from srv netns to cli netns amazingly. 

However, I noticed that the throughput is decreasing drastically after passing every netns from 18728.11(10^6bits/sec) to 1.97(10^6bits/sec) .

thanks,

jason

[Jason Xing]

Hi Neal,

Please ignore this issue. I finally found out that it is the kernel bug which causes the 'tc qdisc add dev [device] root fq' command not to work. The commit I patched this time as following if you're interested:

1) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5133498f4ad1123a5ffd4c08df6431dab882cc32

2) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb420d5d91c1

Thanks,

Jason