From: Isaac Konikoff <konikofi@candelatech.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...
Date: Fri, 27 Feb 2015 11:15:39 -0800 [thread overview]
Message-ID: <54F0C25B.8000607@candelatech.com> (raw)
In-Reply-To: <CAA93jw6HZmMnZb4gd9avzqC20_9uSNdQ6qv69F2kAKsejg6PMg@mail.gmail.com>
It looks like the rtt-fair tests are designed to be run from a single
sta to several host servers such as snapon.lab.bufferbloat.net which
would make the local-bind be the sta. In this case, the upload is up and
the download is down wrt to the sta.
In my case, I'm not using those host servers, I'm using eth1 and
multiple sta's on the same box. So the -H option has the multiple sta's
and eth1 is local-bind. In this case the upload direction is local-bind
to -H or eth1 to sta which is really download.
So, it looks like I need to edit the wrapper conf to get the direction
labels right for essentially a send-to-self test, or just ignore the
labels for now.
Here are some example plots:
http://candelatech.com/downloads/rtt-fair-box.png
http://candelatech.com/downloads/tcp-down.png
http://candelatech.com/downloads/tcp-up.png
On 02/26/2015 09:12 PM, Dave Taht wrote:
> I don't quite get what you mean. Can you mark what you want in gimp or
> inkscape, and put it up somewhere?
>
> (you can post edit the .pdf or .svg versions in inkscape)
>
> On Thu, Feb 26, 2015 at 9:00 PM, Isaac Konikoff
> <konikofi@candelatech.com> wrote:
>> 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
>>> <konikofi@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@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
--
Isaac Konikoff
Candela Technologies
konikofi@candelatech.com
Office: 360-380-1618
Mobile: 360-389-2453
prev parent reply other threads:[~2015-02-27 19:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 2:04 [Cerowrt-devel] " Dave Taht
2015-02-20 5:32 ` [Cerowrt-devel] [Bloat] " Aaron Wood
2015-02-20 8:47 ` Jonathan Morton
2015-02-20 9:03 ` Dave Taht
2015-02-20 17:20 ` dpreed
2015-02-26 0:00 ` Isaac Konikoff
2015-02-26 0:18 ` Jonathan Morton
2015-02-26 0:23 ` Dave Taht
2015-02-26 4:22 ` Isaac Konikoff
2015-02-26 4:37 ` Dave Taht
2015-02-27 5:00 ` Isaac Konikoff
2015-02-27 5:12 ` Dave Taht
2015-02-27 19:15 ` Isaac Konikoff [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F0C25B.8000607@candelatech.com \
--to=konikofi@candelatech.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox