Re: [Make-wifi-fast] less latency, more filling... for wifi

[Bob McMahon <bob.mcmahon@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 4138 bytes --]

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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5551 bytes --]