From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D0ADD3B2A2 for ; Tue, 22 Mar 2016 10:24:16 -0400 (EDT) Received: by mail-oi0-x231.google.com with SMTP id r187so177059885oih.3 for ; Tue, 22 Mar 2016 07:24:16 -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-transfer-encoding; bh=ERbM6zF07i/B9URcRkOO5v8XWM5XZuG2xUHmZuo1qfA=; b=iLgsCa/yPbz41tk82B4mrWpTYMS1tprBuLHUs/CiZzJGPeWX1q0bAJ5px+mHu0CNG0 lF+zivYMJgGP5Fr/KqId8OKC0BM6au2LeXeNQm68iUa8vyL/caLYfy53tRbQE0ACZwzL vLsPbuWivAv1kTGbzAKy93+1odwlOC/IzNEcmYn8ExSTLvGtBh+IPiNwzXMP2QZR0Wdy DikSRgWvpAvGCN8ZNpdA4gSGcb+sar80qKmTHGF76HCZC0GcBsnzIsrabULT2oBBL9fB br0WN+LXX4ejjr667reSAAcwjfDWqkTtV8qcQy0NgWMKWJtAjav/Nw4O1utOoubFbFzv 8TQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ERbM6zF07i/B9URcRkOO5v8XWM5XZuG2xUHmZuo1qfA=; b=OZllrQxBFXDDis+8pZ1uEWanuNjwjSN+cin0ggML7urD3bX1C2Sxsc+DTFxGt4OmtL a1BomzBIdQs6K6pB3JiNsPcUa+q2J4JEQxOVfI5wnkzRWjJOwq7PoljHOthwCq8GkLj2 g0W+9743pak4roJngXqN9DsX+jZCm9T2zxn1F52KM7JC4CB7fkhhyqS87Bbey6B0EVMx GH9BYaO7RZ/uZQL3exu8pbPboie+Yu66MHLy2ZIYz7G39TmZYSHAOffOvrqx3QWL1nyw m4XnmA0dMarwMxvKI+TIJCnfCKosJSN4ZHsL3XVP4uDEGZ2pcWwhh6q6BVucKEj886ri 4ZGw== X-Gm-Message-State: AD7BkJLNgNtiPbEI7VHogpPBd6OceanjszqLEqTY1kb+PPf8qWOHMGAXrp7JmlxgqWm7HTqBGHP4IsMGdsoMlg== MIME-Version: 1.0 X-Received: by 10.202.178.135 with SMTP id b129mr19894660oif.139.1458656655991; Tue, 22 Mar 2016 07:24:15 -0700 (PDT) Received: by 10.202.78.129 with HTTP; Tue, 22 Mar 2016 07:24:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Mar 2016 07:24:15 -0700 Message-ID: From: Dave Taht To: Michal Kazior Cc: Jasmine Strong , linux-wireless , "ath10k@lists.infradead.org" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [RFCv2 0/3] mac80211: implement fq codel X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:24:16 -0000 We have a huge cc list on this thread, and admittedly this work does cut across a great deal of wireless, potentially, but does netdev need to be on it? there's been nothing codel specific on it in a while, so I cut those from the cc. On Tue, Mar 22, 2016 at 1:05 AM, Michal Kazior wr= ote: > On 21 March 2016 at 18:10, Dave Taht wrote: >> thx. >> >> a lot to digest. >> >> A) quick notes on "flent-gui bursts_11e-2016-03-21T09*.gz" >> >> 1) the new bursts_11e test *should* have stuck stuff in the VI and VO >> queues, and there *should* have been some sort of difference shown on >> the plots with it. There wasn't. > > traffic-gen generates only BE traffic. Everything else runs UDP_RR > which doesn't generate a lot of traffic. > > >> For diffserv markings I used BE=3DCS0, BK=3DCS1, VI=3DCS5, and VO=3DEF. >> CS6/CS7 should also land in VO (at least with the soft mac handler >> last I looked). Is there a way to check if you are indeed exercising >> all four 802.11e hardware queues in this test? in ath9k it is the >> "xmit" sysfs var.... > > Hmm.. there are no txq stats. I guess it makes sense to have them? ath9k xmit has been useful to capture. I'm kind of unconvinced those stats are correct, at the moment, but... > There is /sys/kernel/debug/ieee80211/phy*/fq which dumps state of all > queues which will be mostly empty with UDP_RR. You can run netperf UDP > stream with diffserv marking to see onto which tid they are mapped. > You can see tid-AC mappings here: > https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/que= ues We can try to capture those, but sampling summary per-station stats ties back better to actual traffic analysis. Also useful to capture has been the minstrel stats, the minstrel-blues version provided these in a handy csv format. > I just checked and EF ends up as tid5 which is VI. It's actually the > same as CS5. You can use CS7 to run on tid7 which is VO. The intent of CS6 is somewhat incompatible with VO's intent, but we can argue diffserv's usefulness and mappings another day. I have changed the bursts_11e test to use CS7, which will break parsing our previous test runs' data, but actually test what I'd intended to test in the first place. >> 2) In all the old cases the BE UDP_RR flow died on the first burst >> (why?), and the fullpatch preserved it. > > I think it's related to my setup which involves veth pairs. I use them > to simulate bridging/AP behavior but maybe it's not doing the job > right, hmm.. > > >> (I would have kind of hoped to >> have seen the BK flow die, actually, in the fullpatch) > > There's no extra weight priority to BK. The difference between BE and > BK in 802.11 is contention window access time so BK gets less txops > statistically. Both share the same txop, which is 5.484ms in most > cases. Um, well, another day. > >> 3) I am also confused on 802.11ac - can VO aggregate? ( can't in in 802.= 11n). > > Yes, it should be albeit VI and VO have shorter txop compared to > BE/BK: 3.008ms and 1.504ms respectively. Not being able to aggregate in VO in n was a bad thing. There is an awful lot I like about ac over n. > > UDP_RR doesn't really create a lot of opportunities for aggregation. > If you want to see how different queues behave when loaded you'll need > to modify traffic-gen and add bursts across different ACs in the > bursts_11e test. or flood the queues with other tests like rrul or toke's enhancement to traffic-gen. :) I liked being able to arbitrarily mark udp packets ecn capable... > > > Micha=C5=82