From: Michal Kazior <michal.kazior@tieto.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Jasmine Strong <jas@eero.com>,
Network Development <netdev@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Codel] [RFCv2 0/3] mac80211: implement fq codel
Date: Tue, 22 Mar 2016 09:05:32 +0100 [thread overview]
Message-ID: <CA+BoTQ=hgkm2AwMb=kinx+Ezf3vjduCKNH4LNRcV_goDWH4_Vg@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw5AAWua23TbQHZX47XcFLEqU6T=NpxuLqa6FiffBf91Fw@mail.gmail.com>
On 21 March 2016 at 18:10, Dave Taht <dave.taht@gmail.com> 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=CS0, BK=CS1, VI=CS5, and VO=EF.
> 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?
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/queues
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.
> 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.
> 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.
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.
Michał
next prev parent reply other threads:[~2016-03-22 8:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 17:10 Dave Taht
2016-03-22 8:05 ` Michal Kazior [this message]
2016-03-22 9:51 ` Toke Høiland-Jørgensen
-- strict thread matches above, loose matches on Subject: below --
2016-03-16 10:17 Michal Kazior
2016-03-16 10:26 ` Michal Kazior
2016-03-16 15:37 ` Dave Taht
2016-03-16 18:36 ` Dave Taht
2016-03-16 18:55 ` Bob Copeland
2016-03-16 19:49 ` Jasmine Strong
2016-03-17 8:55 ` Michal Kazior
2016-03-17 11:12 ` Bob Copeland
2016-03-17 17:00 ` Dave Taht
2016-03-17 17:24 ` Rick Jones
2016-03-21 11:57 ` Michal Kazior
2016-03-17 9:43 ` Michal Kazior
2016-03-17 9:03 ` Michal Kazior
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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+BoTQ=hgkm2AwMb=kinx+Ezf3vjduCKNH4LNRcV_goDWH4_Vg@mail.gmail.com' \
--to=michal.kazior@tieto.com \
--cc=ath10k@lists.infradead.org \
--cc=codel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=jas@eero.com \
--cc=linux-wireless@vger.kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=netdev@vger.kernel.org \
/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