With such high levels of oversubscription you might want to increase the
socket buffer sizes (using -w)  This will allow the network stack to accept
the application level write() and "drop" them even if the wl driver and
link is saturated.  If the window size is too small the application write()
can block on the WiFi driver returning buffers back to the network stack.
You also need to check kernel level buffers sizes too.

As a side note, trying to test AC priorities by such excessive
oversubscription is not very realistic and not good for any network.   It's
likely driving all queues to a standing queue state and drives latency to a
maximum which is based on the queue maxes, aka bufferbloat.   We've moved
much of our priority (AC) traffic testing to be end/end latency based where
the test traffic doesn't oversubscribe the physical channel for excessive
periods and where the queues can do their job of handling microbursts and
drain, i.e. the service rates on average exceed the input rates.  That's a
much more realistic scenario.  To do latency testing well, one needs the
clocks on the client and server to be synchronized.   You might want to try
with iperf 2.0.13 <https://sourceforge.net/projects/iperf2/> as well.
 There is no test exchange required and UDP should send.  is a -e option as
well as histogram options.  More on those here
<https://sourceforge.net/projects/iperf2/files/Iperf%202.0.13a%20Enhancements.pdf/download>
.

Bob


On Mon, Nov 19, 2018 at 3:26 PM Bruce A. Mah <b...@es.net> wrote:

> If memory serves me right, Kasper Biegun wrote:
>
> > to connect server and client I am using WiFi 5GHz (802.11ac), band:
> > 20MHz with MCS (7 or 8) so I can get 65 to 78 Mbit/s. When I am testing
> > now, I get around 60Mbit/s for the first test and after that second test
> > starts and reaches around 60Mbit/s. But according to my assumptions it
> > should work at the same time and divide possible bandwidth (I set values
> > of TXOPlimit according to 802.11ac standard).
>
> Hi Kasper--
>
> I'm not sure why the tests are serialized.  The only thing I can think
> of is that the first test has completely blocked the wireless link so
> that the second test can't even start.
>
> Wait.  You're testing over wireless?  Yet you're doing 1000Mbps = 1Gbps
> tests.  I don't think there's any wireless link that can handle two
> 1Gbps tests, or even one.  I think you really are saturating the link.
> Because the tests are using UDP they'll just blast out packets at
> whatever rate you specify regardless of whether the path is actually
> capable of supporting it.  You need to turn down the bitrate on both
> tests (especially the first).  What scenario are you trying to simulate
> anyway?
>
> Bruce.
>
> > W dniu 2018-11-19 o 21:50, Bruce A. Mah pisze:
> >
> >> If memory serves me right, Kasper Biegun wrote:
> >>
> >>> currently I'm working on project connected with testing UDP throughput
> >>> for different QoS values. To get the needed results I have to use Best
> >>> Effort (0x70), Background (0x28), Voice (0xc0) and Video (0xb8) traffic
> >>> at the same time. I have troubles with running them, because one stream
> >>> was waiting for another to finish or if they started - only one was
> >>> working (the rest had 0 bandwidth). Then I updated iperf to newest
> >>> version available on github and installed it. Now, for testing
> purposes,
> >>> I am running only Voice and Video at the same time, and I am still
> >>> getting the same issue - one transfer is waiting for the second one to
> >>> finish.
> >>>
> >>> I am using commands:
> >>>
> >>>      - on server: #iperf3 -s -p 5015 and #iperf -s -p 5020
> >>>
> >>>      - on transmitter: #iperf3 -c 10.10.0.1 -p 5015 -S 192 --bind
> >>> 10.10.0.2 --cport 5013 -u -b 1000m and
> >>>
> >>>          #iperf3 -c 10.10.0.1 -p 5020 -S 184 --bind 10.10.0.2 --cport
> >>> 5018 -u -b 1000m
> >>>
> >>> Server is working on Ubuntu 16.04 and transmitter is on Raspberry Pi 3.
> >>>
> >>>
> >>> Could you please help me with that?
> >> Hi Kasper--
> >>
> >> Is it possible that one test is starving the other?  What is the
> >> bandwidth on the path between your server and client?
> >>
> >> (For what it's worth you're setting up the tests correctly by using two
> >> independent sets of client and server.)
> >>
> >> Bruce.
> >>
> >
>
>
> _______________________________________________
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Reply via email to