[Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
konikofi at candelatech.com
Fri Feb 27 00:00:34 EST 2015
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
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
So I setup the virtual sta's to associate with the AP, then run the
following commands for the rtt_fair4be test:
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
Thanks for any help...
On 02/25/2015 08:37 PM, Dave Taht wrote:
> On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
> <konikofi at candelatech.com> wrote:
>> On 02/25/2015 04:23 PM, Dave Taht wrote:
>>> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99 at gmail.com>
>>>>> Here's a comparison plot of box totals:
>>>> 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
>>>> equal?), and the only ones with even halfway acceptable latency are the
>>>> 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
More information about the Cerowrt-devel