[SOLVED] iperf 2.0.5 TCP bidirectional test output out of order

iperf 2.0.5 TCP bidirectional test output out of order

I am using iperf version 2.0.5 to test TCP bandwidth between two machines (Both running Linux Debian 8). I am using dual test to measure bidirectional bandwidth with help of -d, --dualtest option, and I have a python wrapper that grabs test result (using regular expressions), and I rely on order of appearance of the two results in iperf reported output.

However, the reported results keep changing order of appearance, for no appearant reason. They would appear once like this:

Client connecting to ServerIP, TCP port 5002
TCP window size: 0.08 MByte (default)
------------------------------------------------------------
[  5] local ClientIP port 53653 connected with ServerIP port 5002
[  4] local ClientIP port 5002 connected with ServerIP port 46306
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.6 sec  3.00 MBytes  2.36 Mbits/sec
[  4]  0.0-10.7 sec  40.8 MBytes  32.0 Mbits/sec

And other times like this:

Client connecting to ServerIP, TCP port 5002
TCP window size: 0.08 MByte (default)
------------------------------------------------------------
[  5] local ClientIP port 54043 connected with ServerIP port 5002
[  4] local ClientIP port 5002 connected with ServerIP port 46372
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.7 sec  40.8 MBytes  32.0 Mbits/sec
[  5]  0.0-10.7 sec  3.00 MBytes  2.36 Mbits/sec

I have settled my wrapper code to assume the second one, which contains the expected higher bandwidth in the very last line and the other bandwidth in the line right before it.

How do I force a certain order of output reported by iperf?
And why is it using 4 and 5 as ID?
Is there a way to decide what numbers are used for the IDs? Because they seem to be changing from one test to another. That is, it uses 6 and 7 for example when it runs at a different time or from different machines.

This is how I run iperf on the client machine:

iperf -c  ServerIP  -d -p 5002  -f m

and this is on server machine:

iperf -s -p 5002 -D

Solution

There really isn't control over this sequencing as the reporter thread (which outputs the reports) is a separate thread from the traffic threads. Since there are two threads started at the "same time" and running in parallel it's a race to which traffic thread finishes first.

As a side note, iperf 2.0.5 has known bugs and performance enhancements that have been addressed in 2.0.9.

Bob