iperf fails (hangs) in TCP tests #1060
Comments
|
Can you confirm that this issue occurs in the Ubuntu 20.04 VM for Mininet 2.3.0? We don't currently run the CI tests on 21.04 because github actions doesn't support it as a target. However, iperf 2.0.14+ might cause issues in the future on Ubuntu and Debian so it would be nice to have a fix for it if needed. Another test you could run is simply |
|
HI @lantz and thanks for your response. TL;DR
--- details --- My debug started with:
Now from here some iperf seems to work on both just fine:
As next test step I bumped iperf up to 2.0.14a by switchign from the one in Ubuntu to a build from the upstream tarball. Now it hangs, so it really is the new iperf (as assumed before) Since upstream there is a new iperf already let me try that as well And unfortunately 2.1.1-dev behaves just as hanging as 2.0.14a did. The hanging processes on |
|
Have you tried Old iperf: new iperf: It appears that the new I'm not sure of the best way to fix this. As an alternative, we could use Or perhaps we could throw away intervals less than a second. Perhaps you have some thoughts or good ideas. |
|
Hi @lantz Server output:2.0.13 (working)2.0.14a (bad)2.1.1.-devMaybe the output changed not for the defaults, but for the set of arguments mininet is calling it with? |
|
Since you hinted at I see those two calls: Trying those in the three versions (but via 127.0.0.1) ... But OTOH I can confirm running 2.0.132.0.14a2.1.1-devThereby I can confirm your finding of different output and it isn't any different/better in the newest iperf version :-/ |
|
The "extra line" comes from That initial connection is made by mininet via While the new versions better recognize it isn't a real test and now print a line like this Ok, I'm now with you and can follow what you said on your last post and confirm that behavior change :-) |
|
The pre-check for the routing via A alternative could be to parse only client and mostly ignore the server output? How about changing net.py:iperf to just pick "the latest" whatever it is. We only want results from real measurements and The following works well for me with all three iperf versions that I tested --- net.py.orig 2021-03-29 07:28:33.912880284 +0000
+++ net.py 2021-03-29 07:43:39.402620616 +0000
@@ -836,8 +836,7 @@
servout = ''
# We want the last *b/sec from the iperf server output
# for TCP, there are two of them because of waitListening
- count = 2 if l4Type == 'TCP' else 1
- while len( re.findall( '/sec', servout ) ) < count:
+ while len( re.findall( '[1-9]*[0-9]+.0 sec.*/sec', servout ) ):
servout += server.monitor( timeoutms=5000 )
server.sendInt()
servout += server.waitOutput()But then OTOH with the new versions I no more see any difference between the client and the server result anyway. |
|
FYI this issue still remains in upcoming Ubuntu 21.10 (test result) where it tries to run with the newer I'll try to apply the suggestion I have made in the last update above to mininet and check if that would then work with old&new iperf in all our cases. But I'd appreciate if we could rekindle this discussion. |
|
I was testing the fix that I suggested two comments above and for the Ubuntu tests based on mininet that works fine, creates valid results and removed the behavior to hang. |
|
hi, i followed the comment above and changed the code in net.py, but still fails in tcp test(sudo mn --test iperf). any suggestion? |
Expected/Desired Behavior:
TCP based iperf tests to work e.g.
net.iperf( ( h1, h4 ), l4Type='TCP' )Actual Behavior:
UDP based tests work, but once
l4Typeis set to TCP (or left open as it is the default) the test hangs.Detailed Steps to Reproduce the Behavior:
These tests were done in Ubuntu 21.04 Hirsute.
If you need the same OS to test, you can either use a cloud image or use multipass to spawn one easily
You can modify the provided example
simpleperf.pyto show this:On execution that will behave like:
That is seen with iperf 2.0.14a in Debian/Ubuntu.
I thought it is due to the new version that has quite some changes 1 2 3 that eventually became v2.1.
But that wasn't true, at least in my test envronment it happened the same way when I downgraded to
iperf 2.0.13.OTOH if I do a full test reset and run with 2.0.13 it works, so I'd recommend debugging vs 2.0.14a (or later) as that still seems somehow related to this hang.
Downgrading mininet to the former (Ubuntu) version of 2.2.2-5ubuntu1 (last known working setup) is no option as
a) that then triggers a different issue
xception: Error creating interface pair (h1-eth0,s1-eth1):b) the 2.3 python3 version is what I'd eventually want to reach anyway
Additional Information:
When stuck these are the processes left running:
The text was updated successfully, but these errors were encountered: