PS.  Thanks for writing flent and making it available.  I'm a novice w/flent but do plan to learn it.

Bob

On Fri, Oct 13, 2017 at 11:47 AM, Bob McMahon <bob.mcmahon@broadcom.com> wrote:

Hi Toke,

The other thing that will cause the server thread(s) and listener thread to stop is -t when applied to the *server*, i.e. iperf -s -u -t 10 will cause a 10 second timeout for the server/listener thread(s) life.   Some people don't want the Listener to stop so when -D (daemon) is applied, the -t will only terminate server trafffic threads.   Many people asked for this because they wanted a way to time bound these threads, specifically over the life of many tests.

Yeah, summing is a bit of a mess.  I've some proto code I've been playing with but still not sure what is going to be released. 

For UDP, the source port must be unique per the quintuple (ip proto/src ip/ src port/ dst ip/ dst port).  Since the UDP server is merely waiting for packets it doesn't have an knowledge about how to group.  So it groups based upon time, i.e. when a new traffic shows up it's put an existing active group for summing. 

I'm not sure a good way to fix this.  I think the client would have to modify the payload, and  per a -P tell the server the udp src ports that belong in the same group.  Then the server could assign groups based upon a key in the payload.

Thoughts and comments welcome,
Bob

On Fri, Oct 13, 2017 at 2:28 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

Bob McMahon <bob.mcmahon@broadcom.com> writes:

> Thanks Toke. Let me look into this. Is there packet loss during your
> tests? Can you share the output of the client and server per the error
> scenario?

Yeah, there's definitely packet loss.

> With iperf 2 there is no TCP test exchange rather UDP test information
> is derived from packets in flight. The server determines a UDP test is
> finished by detecting a negative sequence number in the payload. In
> theory, this should separate UDP tests. The server detects a new UDP
> stream is by receiving a packet from a new source socket. If the
> packet carrying the negative sequence number is lost then summing
> across "tests" would be expected (even though not desired) per the
> current design and implementation. We intentionally left this as is as
> we didn't want to change the startup behavior nor require the network
> support TCP connections in order to run a UDP test.

Ah, so basically, if the last packet from the client is dropped, the
server is not going to notice that the test ended and just keep
counting? That would definitely explain the behaviour I'm seeing.

So if another test starts from a different source port, the server is
still going to count the same totals? That seems kinda odd :)

> Since we know UDP is unreliable, we do control both client and server over
> ssh pipes, and perform summing in flight per the interval reporting.
>  Operating system signals are used to kill the server.    The iperf sum and
> final reports are ignored.   Unfortunately, I can't publish this package
> with iperf 2 for both technical and licensing reasons.   There is some skeleton
> code in Python 3.5 with asyncio
> <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py> that
> may be of use.   A next step here is to add support for pandas
> <http://pandas.pydata.org/index.html>, and possibly some control chart
> <https://en.wikipedia.org/wiki/Control_chart> techniques (both single and
> multivariate
> <http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc34.htm>) for both
> regressions and outlier detection.

No worries, I already have the setup scripts to handle restarting the
server, and I parse the output with Flent. Just wanted to point out this
behaviour as it was giving me some very odd results before I started
systematically restarting the server...

-Toke