[Make-wifi-fast] less latency, more filling... for wifi
bob.mcmahon at broadcom.com
Fri Oct 13 14:47:19 EDT 2017
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,
On Fri, Oct 13, 2017 at 2:28 AM, Toke Høiland-Jørgensen <toke at toke.dk>
> Bob McMahon <bob.mcmahon at 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
> > ssh pipes, and perform summing in flight per the interval reporting.
> > Operating system signals are used to kill the server. The iperf sum
> > final reports are ignored. Unfortunately, I can't publish this package
> > with iperf 2 for both technical and licensing reasons. There is some
> > code in Python 3.5 with asyncio
> > <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py>
> > 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
> > multivariate
> > <http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc34.htm>) for
> > 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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Make-wifi-fast