<div dir="ltr">Hi Toke,<br><br>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.<br><br>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.  <br><br>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.  <br><br>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.<br><br>Thoughts and comments welcome,<br>Bob</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 2:28 AM, Toke Høiland-Jørgensen <span dir="ltr"><<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.com</a>> writes:<br>
<br>
> Thanks Toke. Let me look into this. Is there packet loss during your<br>
> tests? Can you share the output of the client and server per the error<br>
> scenario?<br>
<br>
</span>Yeah, there's definitely packet loss.<br>
<span class=""><br>
> With iperf 2 there is no TCP test exchange rather UDP test information<br>
> is derived from packets in flight. The server determines a UDP test is<br>
> finished by detecting a negative sequence number in the payload. In<br>
> theory, this should separate UDP tests. The server detects a new UDP<br>
> stream is by receiving a packet from a new source socket. If the<br>
> packet carrying the negative sequence number is lost then summing<br>
> across "tests" would be expected (even though not desired) per the<br>
> current design and implementation. We intentionally left this as is as<br>
> we didn't want to change the startup behavior nor require the network<br>
> support TCP connections in order to run a UDP test.<br>
<br>
</span>Ah, so basically, if the last packet from the client is dropped, the<br>
server is not going to notice that the test ended and just keep<br>
counting? That would definitely explain the behaviour I'm seeing.<br>
<br>
So if another test starts from a different source port, the server is<br>
still going to count the same totals? That seems kinda odd :)<br>
<span class=""><br>
> Since we know UDP is unreliable, we do control both client and server over<br>
> ssh pipes, and perform summing in flight per the interval reporting.<br>
>  Operating system signals are used to kill the server.    The iperf sum and<br>
> final reports are ignored.   Unfortunately, I can't publish this package<br>
> with iperf 2 for both technical and licensing reasons.   There is some skeleton<br>
> code in Python 3.5 with asyncio<br>
</span>> <<a href="https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py" rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>iperf2/code/ci/master/tree/<wbr>flows/flows.py</a>> that<br>
<span class="">> may be of use.   A next step here is to add support for pandas<br>
</span>> <<a href="http://pandas.pydata.org/index.html" rel="noreferrer" target="_blank">http://pandas.pydata.org/<wbr>index.html</a>>, and possibly some control chart<br>
> <<a href="https://en.wikipedia.org/wiki/Control_chart" rel="noreferrer" target="_blank">https://en.wikipedia.org/<wbr>wiki/Control_chart</a>> techniques (both single and<br>
> multivariate<br>
> <<a href="http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc34.htm" rel="noreferrer" target="_blank">http://www.itl.nist.gov/<wbr>div898/handbook/pmc/section3/<wbr>pmc34.htm</a>>) for both<br>
> regressions and outlier detection.<br>
<br>
No worries, I already have the setup scripts to handle restarting the<br>
server, and I parse the output with Flent. Just wanted to point out this<br>
behaviour as it was giving me some very odd results before I started<br>
systematically restarting the server...<br>
<span class="HOEnZb"><font color="#888888"><br>
-Toke<br>
</font></span></blockquote></div><br></div>