Re: [Cerowrt-devel] [Bloat] capturing packets and applying qdiscs

[Aaron Wood <woody77@gmail.com>]

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

I do this often at work, using a separate machine to capture traffic using
wireshark.  Wireshark makes a lot of the analysis fairly straightforward
(especially with it's excellent packet dissectors).  By capturing in
radiotap mode, you get RSSI/noise levels on the 802.11n packet, the rates
involved, everything.  It's very nice for digging into issues.

Unfortunately, the next problem is a "can't see the forest for the trees",
as there are no good high-level analysis tools for captured traffic that
I've found.  Most of the commercial packages seem to offer summary stats,
but not much more (nothing like airtime utilization over time, negotiated
rates over time, aggregate/per-station throughput over time, etc.)


-Aaron

On Fri, Mar 27, 2015 at 9:38 AM, Isaac Konikoff <konikofi@candelatech.com>
wrote:

>
>
> On 03/26/2015 05:39 PM, David Lang wrote:
>
>> On Thu, 26 Mar 2015, Isaac Konikoff wrote:
>>
>>  Hi All,
>>>
>>> Looking for some feedback in my test setup...
>>>
>>> Can you please review my setup and let me know how to improve my
>>> application of the qdiscs? I've been applying manually, but I'm not sure
>>> that is the best method, or if the values really make sense. Sorry if this
>>> has been covered ad nauseum in codel or bloat threads over the past 4+
>>> years...
>>>
>>> I've been capturing packets on a dedicated monitor box using the
>>> following method:
>>>
>>> tshark -i moni1 -w <file>
>>>
>>> where moni1 is ath9k on channel 149 (5745 MHz), width: 40 MHz, center1:
>>> 5755 MHz
>>>
>>> The system under test is a lanforge ath10k ap being driven by another
>>> lanforge system using ath9k clients to associate and run traffic tests.
>>>
>>> The two traffic tests I'm running are:
>>>
>>> 1. netperf-wrapper batch consisting of:  tcp_download, tcp_upload,
>>> tcp_bidirectional, rrul, rrul_be and rtt_fair4be on 4 sta's.
>>>
>>> 2. lanforge wifi capacity test using tcp-download incrementing 4 sta's
>>> per minute up to 64 sta's with each iteration attempting 500Mbps download
>>> per x number of sta's.
>>>
>>
>> what results are you getting? and what results are you hoping to get to?
>>
>> David Lang
>>
> I'll share my results shortly, but the main idea is that I'm doing the
> captures as part of our effort to improve the ath10k driver. Just one
> comparison is that with many clients the ath10k ap throughput tails off
> whereas some non-ath10k ap's are able to sustain high throughput for many
> clients, but even that depends on manufacturer and firmware combos.
>
> I'll be able to point this behaviour out better once I get the files
> uploaded...
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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