From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BEAFD21F3F0; Fri, 27 Mar 2015 10:15:55 -0700 (PDT) Received: by qgf60 with SMTP id 60so121160233qgf.3; Fri, 27 Mar 2015 10:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uNfKHq/tauSglUSihsb2M6KzROIEfjCNZYRrq0PAXAM=; b=HXTacHhKD/MnJ6fDVOsInSHD7iVww9YcRQps0Q5MvEkllLCCgoEAPF6unKz+s/0ZGX hk5/1KYnSRgzIFg0vXHk+BLjbeod7lhN0Ro3VxUBi/SH05y5H3cfLwO2ntM6sbSzchik sB8nTfNZOpRbh33IfrAZVYopNM/SvwVypp2A4N1SPJLoPrfjttJ6pqP6FiGU0zflqm5H W5mvgiYlaOulV6k9pkYx0Kc1jTk6yJHzVl7eV9sqywMwbNfH1Uub2ygDcrTluzQ96X3u gefYZdweqprq1AUyXPYox/Tu1zWzx8eBobSYryM9ReQWwxIwNG9iaTEdtY1PJGaGa1Om gVPQ== MIME-Version: 1.0 X-Received: by 10.140.150.193 with SMTP id 184mr25173248qhw.100.1427476553980; Fri, 27 Mar 2015 10:15:53 -0700 (PDT) Received: by 10.96.175.65 with HTTP; Fri, 27 Mar 2015 10:15:53 -0700 (PDT) In-Reply-To: <5515879C.2030602@candelatech.com> References: <55147C8A.4030804@candelatech.com> <5515879C.2030602@candelatech.com> Date: Fri, 27 Mar 2015 10:15:53 -0700 Message-ID: From: Aaron Wood To: Isaac Konikoff Content-Type: multipart/alternative; boundary=001a11353a76ece0ad05124848ff Cc: codel , cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] capturing packets and applying qdiscs X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:16:24 -0000 --001a11353a76ece0ad05124848ff Content-Type: text/plain; charset=UTF-8 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 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 >>> >>> 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 > --001a11353a76ece0ad05124848ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do this often at work, using a separate machine to captu= re traffic using wireshark.=C2=A0 Wireshark makes a lot of the analysis fai= rly straightforward (especially with it's excellent packet dissectors).= =C2=A0 By capturing in radiotap mode, you get RSSI/noise levels on the 802.= 11n packet, the rates involved, everything.=C2=A0 It's very nice for di= gging into issues.

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

<= br>
-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 applicatio= n 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 follow= ing method:

tshark -i moni1 -w <file>

where moni1 is ath9k on channel 149 (5745 MHz), width: 40 MHz, center1: 575= 5 MHz

The system under test is a lanforge ath10k ap being driven by another lanfo= rge system using ath9k clients to associate and run traffic tests.

The two traffic tests I'm running are:

1. netperf-wrapper batch consisting of:=C2=A0 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 downlo= ad 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 c= omparison is that with many clients the ath10k ap throughput tails off wher= eas some non-ath10k ap's are able to sustain high throughput for many c= lients, but even that depends on manufacturer and firmware combos.

I'll be able to point this behaviour out better once I get the files up= loaded...



_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat

--001a11353a76ece0ad05124848ff--