* [Cerowrt-devel] looking over ampdu stats
@ 2014-01-19 17:20 Dave Taht
2014-01-20 3:27 ` Sujith Manoharan
0 siblings, 1 reply; 6+ messages in thread
From: Dave Taht @ 2014-01-19 17:20 UTC (permalink / raw)
To: cerowrt-devel
in my tests, we almost never see more than 2 AMPDUs stacked up. (just
running netperf, not rrul). This could be the fault of the client
device I'm using...
cat /sys/kernel/debug/ieee80211/phy1/ath9k/queues
(note: have set the default be_qlen to the default here)
(VO): qnum: 0 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
(VI): qnum: 1 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
(BE): qnum: 2 qdepth: 3 ampdu-depth: 2 pending: 60 stopped: 0
(BK): qnum: 3 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
(CAB): qnum: 8 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] looking over ampdu stats
2014-01-19 17:20 [Cerowrt-devel] looking over ampdu stats Dave Taht
@ 2014-01-20 3:27 ` Sujith Manoharan
2014-01-20 3:38 ` Dave Taht
0 siblings, 1 reply; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-20 3:27 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
Dave Taht wrote:
> in my tests, we almost never see more than 2 AMPDUs stacked up. (just
> running netperf, not rrul).
2 is the minimum queue depth to aggregate packets. From ath9k.h:
#define ATH_AGGR_MIN_QDEPTH 2
> This could be the fault of the client device I'm using...
This is not a bug with the client.
> cat /sys/kernel/debug/ieee80211/phy1/ath9k/queues
>
> (note: have set the default be_qlen to the default here)
>
> (VO): qnum: 0 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
> (VI): qnum: 1 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
> (BE): qnum: 2 qdepth: 3 ampdu-depth: 2 pending: 60 stopped: 0
> (BK): qnum: 3 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
> (CAB): qnum: 8 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
qlen will not affect the minimum aggregate threshold, so adjusting
be_qlen will not affect aggregation.
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] looking over ampdu stats
2014-01-20 3:27 ` Sujith Manoharan
@ 2014-01-20 3:38 ` Dave Taht
2014-01-20 3:55 ` Sujith Manoharan
0 siblings, 1 reply; 6+ messages in thread
From: Dave Taht @ 2014-01-20 3:38 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: cerowrt-devel
On Sun, Jan 19, 2014 at 10:27 PM, Sujith Manoharan <sujith@msujith.org> wrote:
> Dave Taht wrote:
>> in my tests, we almost never see more than 2 AMPDUs stacked up. (just
>> running netperf, not rrul).
>
> 2 is the minimum queue depth to aggregate packets. From ath9k.h:
> #define ATH_AGGR_MIN_QDEPTH 2
>
>> This could be the fault of the client device I'm using...
>
> This is not a bug with the client.
Gotcha. I went later (at felix's urging) to look at the rc_stats
and that showed some decent averages for the actual number of
packets in the AMPDU. Never managed to get it much above 11,
regardless of what I set be_qlen to...
>
>> cat /sys/kernel/debug/ieee80211/phy1/ath9k/queues
>>
>> (note: have set the default be_qlen to the default here)
>>
>> (VO): qnum: 0 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
>> (VI): qnum: 1 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
>> (BE): qnum: 2 qdepth: 3 ampdu-depth: 2 pending: 60 stopped: 0
>> (BK): qnum: 3 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
>> (CAB): qnum: 8 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0
>
> qlen will not affect the minimum aggregate threshold, so adjusting
> be_qlen will not affect aggregation.
Well, it sort of does (or used to) in that cero holds this value low (12)
to minimize latency. While this costs some throughput it seems to help
in low rate situations.
>
> Sujith
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] looking over ampdu stats
2014-01-20 3:38 ` Dave Taht
@ 2014-01-20 3:55 ` Sujith Manoharan
2014-01-20 15:09 ` David P. Reed
0 siblings, 1 reply; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-20 3:55 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
Dave Taht wrote:
> Gotcha. I went later (at felix's urging) to look at the rc_stats
> and that showed some decent averages for the actual number of
> packets in the AMPDU. Never managed to get it much above 11,
> regardless of what I set be_qlen to...
Yes, something seems to be wrong.
Using just 1 stream with iperf, the average A-MPDU length never
goes above 10 and the throughput is about 90 Mbps.
Using 4 iperf streams (using -P), the average A-MPDU length goes up to 22
and throughput reaches about 102 Mbps.
This is with HT20. Using HT40 shows the behavior for 1 iperf stream.
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] looking over ampdu stats
2014-01-20 3:55 ` Sujith Manoharan
@ 2014-01-20 15:09 ` David P. Reed
2014-01-20 15:35 ` Sujith Manoharan
0 siblings, 1 reply; 6+ messages in thread
From: David P. Reed @ 2014-01-20 15:09 UTC (permalink / raw)
To: Sujith Manoharan, Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
It's worth remembering that while aggregation of data in single units might reduce overhead, end to end latency is far more critical to most Internet apps.
Focusing on optimizing throughput for the last few percent in corner cases is NOT desirable. In fact, it is the cause of pervasive buffer bloated designs, and the creator of "Daddy broke the Internet" scenarios.
Since LTE is badly configured in the field for Internet use, causing denial of service to many users because of bloated (multisecond to drain) queues, I would stop focusing on this, which is only a 10 percent issue. Multisecond bloat is a disaster. You are fiddling while Rome burns imo.
On Jan 19, 2014, Sujith Manoharan <sujith@msujith.org> wrote:
>Dave Taht wrote:
>> Gotcha. I went later (at felix's urging) to look at the rc_stats
>> and that showed some decent averages for the actual number of
>> packets in the AMPDU. Never managed to get it much above 11,
>> regardless of what I set be_qlen to...
>
>Yes, something seems to be wrong.
>
>Using just 1 stream with iperf, the average A-MPDU length never
>goes above 10 and the throughput is about 90 Mbps.
>
>Using 4 iperf streams (using -P), the average A-MPDU length goes up to
>22
>and throughput reaches about 102 Mbps.
>
>This is with HT20. Using HT40 shows the behavior for 1 iperf stream.
>
>Sujith
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Sent from my Android device with <a href=https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2><b>K-@ Mail</b></a>. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2173 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] looking over ampdu stats
2014-01-20 15:09 ` David P. Reed
@ 2014-01-20 15:35 ` Sujith Manoharan
0 siblings, 0 replies; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-20 15:35 UTC (permalink / raw)
To: David P. Reed; +Cc: cerowrt-devel
David P. Reed wrote:
> It's worth remembering that while aggregation of data in single units might
> reduce overhead, end to end latency is far more critical to most Internet
> apps.
>
> Focusing on optimizing throughput for the last few percent in corner cases is
> NOT desirable. In fact, it is the cause of pervasive buffer bloated designs,
> and the creator of "Daddy broke the Internet" scenarios.
>
> Since LTE is badly configured in the field for Internet use, causing denial of
> service to many users because of bloated (multisecond to drain) queues, I
> would stop focusing on this, which is only a 10 percent issue. Multisecond
> bloat is a disaster. You are fiddling while Rome burns imo.
Well, the 10 percent is with a 1x1 card. It becomes worse with 2x2 and with 3x3,
it's really bad - about 180 Mbps when it should be close to 290 Mbps. Using more
parallel threads appears to improve things, but I don't see this behavior with
a windows client, where a single iperf stream gives good results, unlike ath9k.
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-20 15:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-19 17:20 [Cerowrt-devel] looking over ampdu stats Dave Taht
2014-01-20 3:27 ` Sujith Manoharan
2014-01-20 3:38 ` Dave Taht
2014-01-20 3:55 ` Sujith Manoharan
2014-01-20 15:09 ` David P. Reed
2014-01-20 15:35 ` Sujith Manoharan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox