Something I'm not quite getting on the rtt_fair tests is that the upload
and download labels do not look right for my test setup...how can I use
netperf-wrapper better?
The lanforge box is sending and receiving all traffic with the AP under
test in the middle, where eth1 to staX is download and staX to eth1 is
upload.
So I setup the virtual sta's to associate with the AP, then run the
following commands for the rtt_fair4be test:
netserver
netperf-wrapper -H sta1 -H sta2 -H sta3 -H sta4 --local-bind eth1 -x -t
netgear6300 rtt_fair4be -f plot
However if I run a tcp_upload, tcp_download or tcp_bidirectional I can
change the order of the arguments so that the upload/download labels
match what each interface is reporting:
netperf-wrapper -H eth1 --local-bind sta1 -x -t netgear6300 tcp_download
-f plot
Thanks for any help...
Isaac
On 02/25/2015 08:37 PM, Dave Taht wrote:
On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
<konik...@candelatech.com> wrote:
On 02/25/2015 04:23 PM, Dave Taht wrote:
On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromati...@gmail.com>
wrote:
Here's a comparison plot of box totals:
http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
That's a real mess. All of them utterly fail to get download bandwidth
anywhere near the upload (am I right in assuming it should ideally be
about
equal?), and the only ones with even halfway acceptable latency are the
ones
with least throughput in either direction.
And I suspect that this was a test at the highest possible MCS rates
and txpower. Isaac?
Yes, highest MCS for each AP and fw defaulted tx power. I can experiment
with attenuation and lower MCS rates as well.
Be prepared to be horrified in disbelief at your results at the lower
rates... and post them anyway.
I note that rtt_fair4be is a pretty stressful, artificial benchmark,
and to truly stress things out requires more
than one tcp flow per station in each direction, or attempting to also
exercise the 802.11e queues. Or interference. Or multicast.
I do believe, that once these enormous latencies are clobbered via
various techniques in make-wifi-fast that it is possible to get
bandwidth per station over tcp to degrade nearly linearly, and achieve
close to the theoretical rate of the air, and for latencies to remain
(on this 4 station test) typically in the 4-14ms range at all but the
lowest MCS rates.
IMHO an AP that one day does well on these tests will also do much
better on a variety of others. :)
btw, I show a detailed graph of TCP's actual behavior under
circumstances like these
at nearly every talk, with data taken on the actual conference wifi.
It never occurred to me once, to show the bar chart! (out of the 14+
plots available).
It might be helpful on your next test run to also do the simplest
tests to a single station over each AP
for a reference (tcp_upload, tcp_download, and tcp_bidirectional).
- Jonathan Morton
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
