From: Michal Kazior <michal.kazior@tieto.com>
To: Jasmine Strong <jas@eero.com>
Cc: Bob Copeland <me@bobcopeland.com>,
Dave Taht <dave.taht@gmail.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: [RFCv2 0/3] mac80211: implement fq codel
Date: Thu, 17 Mar 2016 09:55:03 +0100 [thread overview]
Message-ID: <CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg@mail.gmail.com> (raw)
In-Reply-To: <CAGyitvMDEUiNx7HD=XKjXNHnFvZ_gxD_BbQx3AP-57_+dBeD4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
TxOP 0 has a special meaning in the standard. For HT/VHT it means the
it is actually limited to 5484us (mixed-mode) or 10000us (greenfield).
I suspect the BK/BE latency difference has to do with the fact that
there's bulk traffic going on BE queues (this isn't reflected
explicitly in the plots). The `bursts` flent test includes short
bursts of traffic on tid0 (BE) which is shared with ICMP and BE UDP_RR
(seen as green and blue lines on the plot). Due to (intended) limited
outflow (6mbps) BE queues build up and don't drain for the duration of
the entire test creating more opportunities for aggregating BE traffic
while other queues are near-empty and very short (time wise as well).
If you consider Wi-Fi is half-duplex and latency in the entire stack
(for processing ICMP and UDP_RR) is greater than 11e contention window
timings you can get your BE flow responses with extra delay (since
other queues might have responses ready quicker).
I've modified traffic-gen and re-run tests with bursts on all tested
tids/ACs (tid0, tid1, tid5). I'm attaching the results.
With bursts on all tids you can clearly see BK has much higher latency than BE.
(Note, I've changed my AP to QCA988X with oldie firmware 10.1.467 for
this test; it doesn't have the weird hiccups I was seeing on QCA99X0
and newer QCA988X firmware reports bogus expected throughput which is
most likely a result of my sloppy proof-of-concept change in ath10k).
Michał
On 16 March 2016 at 20:48, Jasmine Strong <jas@eero.com> wrote:
> BK usually has 0 txop, so it doesn't do aggregation.
>
> On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
>> > That is the sanest 802.11e queue behavior I have ever seen! (at both
>> > 6 and 300mbit! in the ath10k patched mac test)
>>
>> Out of curiosity, why does BE have larger latency than BK in that chart?
>> I'd have expected the opposite.
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>
[-- Attachment #2: bursts-2016-03-17T083932.549858.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 14649 bytes --]
[-- Attachment #3: bursts-2016-03-17T083803.348752.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 15029 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michal Kazior <michal.kazior@tieto.com>
To: Jasmine Strong <jas@eero.com>
Cc: 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,
Bob Copeland <me@bobcopeland.com>
Subject: Re: [RFCv2 0/3] mac80211: implement fq codel
Date: Thu, 17 Mar 2016 09:55:03 +0100 [thread overview]
Message-ID: <CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg@mail.gmail.com> (raw)
In-Reply-To: <CAGyitvMDEUiNx7HD=XKjXNHnFvZ_gxD_BbQx3AP-57_+dBeD4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
TxOP 0 has a special meaning in the standard. For HT/VHT it means the
it is actually limited to 5484us (mixed-mode) or 10000us (greenfield).
I suspect the BK/BE latency difference has to do with the fact that
there's bulk traffic going on BE queues (this isn't reflected
explicitly in the plots). The `bursts` flent test includes short
bursts of traffic on tid0 (BE) which is shared with ICMP and BE UDP_RR
(seen as green and blue lines on the plot). Due to (intended) limited
outflow (6mbps) BE queues build up and don't drain for the duration of
the entire test creating more opportunities for aggregating BE traffic
while other queues are near-empty and very short (time wise as well).
If you consider Wi-Fi is half-duplex and latency in the entire stack
(for processing ICMP and UDP_RR) is greater than 11e contention window
timings you can get your BE flow responses with extra delay (since
other queues might have responses ready quicker).
I've modified traffic-gen and re-run tests with bursts on all tested
tids/ACs (tid0, tid1, tid5). I'm attaching the results.
With bursts on all tids you can clearly see BK has much higher latency than BE.
(Note, I've changed my AP to QCA988X with oldie firmware 10.1.467 for
this test; it doesn't have the weird hiccups I was seeing on QCA99X0
and newer QCA988X firmware reports bogus expected throughput which is
most likely a result of my sloppy proof-of-concept change in ath10k).
Michał
On 16 March 2016 at 20:48, Jasmine Strong <jas@eero.com> wrote:
> BK usually has 0 txop, so it doesn't do aggregation.
>
> On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
>> > That is the sanest 802.11e queue behavior I have ever seen! (at both
>> > 6 and 300mbit! in the ath10k patched mac test)
>>
>> Out of curiosity, why does BE have larger latency than BK in that chart?
>> I'd have expected the opposite.
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>
[-- Attachment #2: bursts-2016-03-17T083932.549858.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 14649 bytes --]
[-- Attachment #3: bursts-2016-03-17T083803.348752.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 15029 bytes --]
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
WARNING: multiple messages have this Message-ID (diff)
From: Michal Kazior <michal.kazior@tieto.com>
To: Jasmine Strong <jas@eero.com>
Cc: Network Development <netdev@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Dave Taht <dave.taht@gmail.com>,
"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
make-wifi-fast@lists.bufferbloat.net,
Bob Copeland <me@bobcopeland.com>
Subject: Re: [RFCv2 0/3] mac80211: implement fq codel
Date: Thu, 17 Mar 2016 09:55:03 +0100 [thread overview]
Message-ID: <CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg@mail.gmail.com> (raw)
In-Reply-To: <CAGyitvMDEUiNx7HD=XKjXNHnFvZ_gxD_BbQx3AP-57_+dBeD4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
TxOP 0 has a special meaning in the standard. For HT/VHT it means the
it is actually limited to 5484us (mixed-mode) or 10000us (greenfield).
I suspect the BK/BE latency difference has to do with the fact that
there's bulk traffic going on BE queues (this isn't reflected
explicitly in the plots). The `bursts` flent test includes short
bursts of traffic on tid0 (BE) which is shared with ICMP and BE UDP_RR
(seen as green and blue lines on the plot). Due to (intended) limited
outflow (6mbps) BE queues build up and don't drain for the duration of
the entire test creating more opportunities for aggregating BE traffic
while other queues are near-empty and very short (time wise as well).
If you consider Wi-Fi is half-duplex and latency in the entire stack
(for processing ICMP and UDP_RR) is greater than 11e contention window
timings you can get your BE flow responses with extra delay (since
other queues might have responses ready quicker).
I've modified traffic-gen and re-run tests with bursts on all tested
tids/ACs (tid0, tid1, tid5). I'm attaching the results.
With bursts on all tids you can clearly see BK has much higher latency than BE.
(Note, I've changed my AP to QCA988X with oldie firmware 10.1.467 for
this test; it doesn't have the weird hiccups I was seeing on QCA99X0
and newer QCA988X firmware reports bogus expected throughput which is
most likely a result of my sloppy proof-of-concept change in ath10k).
Michał
On 16 March 2016 at 20:48, Jasmine Strong <jas@eero.com> wrote:
> BK usually has 0 txop, so it doesn't do aggregation.
>
> On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
>> > That is the sanest 802.11e queue behavior I have ever seen! (at both
>> > 6 and 300mbit! in the ath10k patched mac test)
>>
>> Out of curiosity, why does BE have larger latency than BK in that chart?
>> I'd have expected the opposite.
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>
[-- Attachment #2: bursts-2016-03-17T083932.549858.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 14649 bytes --]
[-- Attachment #3: bursts-2016-03-17T083803.348752.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 15029 bytes --]
[-- Attachment #4: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-03-17 8:55 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 10:17 [RFCv2 0/3] mac80211: implement fq codel Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-16 10:17 ` [RFCv2 1/3] mac80211: implement fq_codel for software queuing Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-22 1:35 ` [Make-wifi-fast] " David Lang
2016-03-22 1:35 ` David Lang
2016-03-22 1:35 ` David Lang
2016-03-22 6:51 ` Michal Kazior
2016-03-22 6:51 ` Michal Kazior
2016-03-22 6:51 ` Michal Kazior
2016-03-16 10:17 ` [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211 Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-24 7:19 ` Mohammed Shafi Shajakhan
2016-03-24 7:19 ` Mohammed Shafi Shajakhan
2016-03-24 7:19 ` Mohammed Shafi Shajakhan
2016-03-24 7:49 ` Michal Kazior
2016-03-24 7:49 ` Michal Kazior
2016-03-24 7:49 ` Michal Kazior
2016-03-24 12:23 ` Mohammed Shafi Shajakhan
2016-03-24 12:23 ` Mohammed Shafi Shajakhan
2016-03-24 12:31 ` Michal Kazior
2016-03-24 12:31 ` Michal Kazior
2016-03-24 12:31 ` Michal Kazior
2016-03-16 10:17 ` [RFCv2 3/3] ath10k: use ieee80211_tx_schedule() Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-16 10:17 ` Michal Kazior
2016-03-16 10:26 ` [RFCv2 0/3] mac80211: implement fq codel Michal Kazior
2016-03-16 10:26 ` Michal Kazior
2016-03-16 15:37 ` Dave Taht
2016-03-16 15:37 ` Dave Taht
2016-03-16 15:37 ` Dave Taht
2016-03-16 18:36 ` Dave Taht
2016-03-16 18:36 ` Dave Taht
2016-03-16 18:36 ` Dave Taht
2016-03-16 18:55 ` Bob Copeland
2016-03-16 18:55 ` Bob Copeland
2016-03-16 18:55 ` Bob Copeland
2016-03-16 19:48 ` Jasmine Strong
2016-03-17 8:55 ` Michal Kazior [this message]
2016-03-17 8:55 ` Michal Kazior
2016-03-17 8:55 ` Michal Kazior
2016-03-17 11:12 ` Bob Copeland
2016-03-17 11:12 ` Bob Copeland
2016-03-17 17:00 ` Dave Taht
2016-03-17 17:00 ` Dave Taht
2016-03-17 17:00 ` Dave Taht
2016-03-17 17:24 ` [Codel] " Rick Jones
2016-03-17 17:24 ` Rick Jones
2016-03-17 17:24 ` Rick Jones
2016-03-21 11:57 ` Michal Kazior
2016-03-21 11:57 ` Michal Kazior
2016-03-17 9:43 ` Michal Kazior
2016-03-17 9:43 ` Michal Kazior
2016-03-17 9:43 ` Michal Kazior
2016-03-17 9:03 ` Michal Kazior
2016-03-17 9:03 ` Michal Kazior
2016-03-17 9:03 ` Michal Kazior
2016-03-25 9:27 ` [PATCH 0/2] mac80211: implement fq_codel Michal Kazior
2016-03-25 9:27 ` [PATCH 1/2] mac80211: implement fair queuing per txq Michal Kazior
2016-04-08 4:37 ` Avery Pennarun
2016-04-11 7:25 ` Michal Kazior
2016-03-25 9:27 ` [PATCH 2/2] mac80211: expose some txq/fq internals and knobs via debugfs Michal Kazior
2016-03-31 10:28 ` [PATCHv2 0/2] mac80211: implement fq_codel Michal Kazior
2016-03-31 10:28 ` [PATCHv2 1/2] mac80211: implement fair queuing per txq Michal Kazior
2016-04-05 13:57 ` Johannes Berg
2016-04-05 14:32 ` Dave Taht
2016-04-06 7:21 ` Johannes Berg
2016-04-06 17:39 ` Dave Taht
2016-04-07 8:53 ` Johannes Berg
2016-04-06 5:35 ` Michal Kazior
2016-04-06 6:03 ` [Make-wifi-fast] " Jonathan Morton
2016-04-06 7:16 ` Michal Kazior
2016-04-06 16:46 ` Jonathan Morton
2016-04-06 7:19 ` Johannes Berg
2016-03-31 10:28 ` [PATCHv2 2/2] mac80211: expose some txq/fq internals and knobs via debugfs Michal Kazior
2016-04-14 12:18 ` [PATCHv3 0/5] mac80211: implement fq_codel Michal Kazior
2016-04-14 12:18 ` [PATCHv3 1/5] mac80211: skip netdev queue control with software queuing Michal Kazior
2016-04-16 22:21 ` Johannes Berg
2016-04-18 5:39 ` Michal Kazior
2016-04-14 12:18 ` [PATCHv3 2/5] mac80211: implement fair queueing per txq Michal Kazior
2016-04-16 22:23 ` Johannes Berg
2016-04-16 22:25 ` Johannes Berg
2016-04-18 5:16 ` Michal Kazior
2016-04-18 12:31 ` [Codel] " Eric Dumazet
2016-04-18 13:36 ` Michal Kazior
2016-04-19 9:10 ` Johannes Berg
2016-04-14 12:18 ` [PATCHv3 3/5] mac80211: add debug knobs for fair queuing Michal Kazior
2016-04-14 12:18 ` [PATCHv3 4/5] mac80211: implement codel on fair queuing flows Michal Kazior
2016-04-16 22:29 ` Johannes Berg
2016-04-18 5:31 ` Michal Kazior
2016-04-18 12:38 ` Michal Kazior
2016-04-19 9:06 ` Johannes Berg
2016-04-19 9:31 ` Michal Kazior
2016-04-19 9:57 ` Johannes Berg
2016-04-14 12:18 ` [PATCHv3 5/5] mac80211: add debug knobs for codel Michal Kazior
2016-05-05 11:00 ` [PATCHv4 0/5] mac80211: implement fq_codel Michal Kazior
2016-05-05 11:00 ` [PATCHv4 1/5] mac80211: skip netdev queue control with software queuing Michal Kazior
2016-05-09 12:28 ` Michal Kazior
2016-05-05 11:00 ` [PATCHv4 2/5] mac80211: implement fair queueing per txq Michal Kazior
2016-05-05 11:00 ` [PATCHv4 3/5] mac80211: add debug knobs for fair queuing Michal Kazior
2016-06-09 9:48 ` Johannes Berg
2016-05-05 11:00 ` [PATCHv4 4/5] mac80211: implement codel on fair queuing flows Michal Kazior
2016-05-05 15:30 ` Dave Taht
2016-05-05 11:00 ` [PATCHv4 5/5] mac80211: add debug knobs for codel Michal Kazior
2016-05-05 15:21 ` Dave Taht
2016-05-06 5:27 ` Michal Kazior
2016-05-06 5:51 ` Dave Taht
2016-05-06 6:33 ` Michal Kazior
2016-05-06 7:23 ` Dave Taht
2016-05-19 8:37 ` [PATCHv5 0/5] mac80211: implement fq_codel Michal Kazior
2016-05-19 8:37 ` [PATCHv5 1/5] mac80211: skip netdev queue control with software queuing Michal Kazior
2016-05-19 8:37 ` [PATCHv5 2/5] mac80211: implement fair queueing per txq Michal Kazior
2016-05-19 8:37 ` [PATCHv5 3/5] mac80211: add debug knobs for fair queuing Michal Kazior
2016-05-19 8:37 ` [PATCHv5 4/5] mac80211: implement codel on fair queuing flows Michal Kazior
2016-05-19 8:37 ` [PATCHv5 5/5] mac80211: add debug knobs for codel Michal Kazior
2016-06-09 9:47 ` Johannes Berg
2016-05-31 12:12 ` [Make-wifi-fast] [PATCHv5 0/5] mac80211: implement fq_codel Toke Høiland-Jørgensen
2016-05-31 12:31 ` Michal Kazior
2016-06-09 9:49 ` Johannes Berg
2016-03-21 17:10 [RFCv2 0/3] mac80211: implement fq codel Dave Taht
2016-03-21 17:10 ` Dave Taht
2016-03-21 17:10 ` Dave Taht
2016-03-22 8:05 ` Michal Kazior
2016-03-22 8:05 ` Michal Kazior
2016-03-22 8:05 ` Michal Kazior
2016-03-22 9:51 ` Toke Høiland-Jørgensen
2016-03-22 9:51 ` Toke Høiland-Jørgensen
2016-03-22 9:51 ` Toke Høiland-Jørgensen
2016-03-22 14:24 ` Dave Taht
2016-03-22 14:24 ` Dave Taht
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg@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=me@bobcopeland.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.