* [ath9k-devel] Debugging very slow ath9k AP performance
@ 2012-04-05 23:12 Ben Greear
2012-04-05 23:19 ` Ben Greear
0 siblings, 1 reply; 3+ messages in thread
From: Ben Greear @ 2012-04-05 23:12 UTC (permalink / raw)
To: ath9k-devel
I am seeing very slow performance when I have around 100
stations connected to an AP (ath9k on both ends).
It seems like the station side is doing fine, but on the
AP side, it appears there are always lots of pending frames
and it is only transmitting about 100 pkts per second if my stats
are correct.
Kernel is 3.3.1+ with the troublesome ath9k patch reverted.
I would be greatful for any pointers as to what might be
causing this slowdown.
[root at lanner-atom ~]# cat /debug/ieee80211/wiphy0/ath9k/xmit
Num-Tx-Queues: 10 tx-queues-setup: 0x10f poll-work-seen: 7113 Off-Channel: No
BE BK VI VO
MPDUs Queued: 77539 0 0 7717
MPDUs Completed: 77213 0 0 7584
MPDUs XRetried: 326 0 0 133
Aggregates: 391465 0 0 0
AMPDUs Queued HW: 1080 0 0 0
AMPDUs Queued SW: 588156 0 0 0
AMPDUs Completed: 503120 0 0 0
AMPDUs Retried: 1033333 0 0 0
AMPDUs XRetried: 85992 0 0 0
FIFO Underrun: 0 0 0 0
TXOP Exceeded: 0 0 0 0
TXTIMER Expiry: 0 0 0 0
DESC CFG Error: 0 0 0 0
DATA Underrun: 0 0 0 0
DELIM Underrun: 0 0 0 0
TX-Pkts-All: 666651 0 0 7717
TX-Bytes-All: 816440297 0 0 633824
hw-put-tx-buf: 952507 0 0 5766
hw-tx-start: 0 0 0 0
hw-tx-proc-desc: 0 0 0 0
TX-Failed: 0 0 0 0
txq-memory-address: f6bc1df0 f6bc1e8c f6bc1d54 f6bc1cb8
axq-qnum: 2 3 1 0
axq-depth: 2 0 0 0
axq-ampdu_depth: 2 0 0 0
axq-stopped 1 0 0 0
tx-in-progress 0 0 0 0
pending-frames 123 0 0 0
txq_headidx: 3 0 0 6
txq_tailidx: 3 0 0 6
axq_q empty: 1 1 1 1
axq_acq empty: 0 1 1 1
txq_fifo[0] empty: 1 1 1 1
txq_fifo[1] empty: 0 1 1 1
txq_fifo[2] empty: 0 1 1 1
txq_fifo[3] empty: 1 1 1 1
txq_fifo[4] empty: 1 1 1 1
txq_fifo[5] empty: 1 1 1 1
txq_fifo[6] empty: 1 1 1 1
txq_fifo[7] empty: 1 1 1 1
txq[2] first-ac: f3da7a00 sched: 1
first-tid: f3da73c8 sched: 1 paused: 0
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 3+ messages in thread* [ath9k-devel] Debugging very slow ath9k AP performance
2012-04-05 23:12 [ath9k-devel] Debugging very slow ath9k AP performance Ben Greear
@ 2012-04-05 23:19 ` Ben Greear
2012-04-06 1:13 ` Ben Greear
0 siblings, 1 reply; 3+ messages in thread
From: Ben Greear @ 2012-04-05 23:19 UTC (permalink / raw)
To: ath9k-devel
On 04/05/2012 04:12 PM, Ben Greear wrote:
> I am seeing very slow performance when I have around 100
> stations connected to an AP (ath9k on both ends).
>
> It seems like the station side is doing fine, but on the
> AP side, it appears there are always lots of pending frames
> and it is only transmitting about 100 pkts per second if my stats
> are correct.
>
> Kernel is 3.3.1+ with the troublesome ath9k patch reverted.
>
> I would be greatful for any pointers as to what might be
> causing this slowdown.
Hrm, just noticed dmesg is full of these messages:
ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7658178
ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7658178
net_ratelimit: 33 callbacks suppressed
ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7671545
Will have to go figure out what that means...
Ben
>
>
> [root at lanner-atom ~]# cat /debug/ieee80211/wiphy0/ath9k/xmit
> Num-Tx-Queues: 10 tx-queues-setup: 0x10f poll-work-seen: 7113 Off-Channel: No
> BE BK VI VO
>
> MPDUs Queued: 77539 0 0 7717
> MPDUs Completed: 77213 0 0 7584
> MPDUs XRetried: 326 0 0 133
> Aggregates: 391465 0 0 0
> AMPDUs Queued HW: 1080 0 0 0
> AMPDUs Queued SW: 588156 0 0 0
> AMPDUs Completed: 503120 0 0 0
> AMPDUs Retried: 1033333 0 0 0
> AMPDUs XRetried: 85992 0 0 0
> FIFO Underrun: 0 0 0 0
> TXOP Exceeded: 0 0 0 0
> TXTIMER Expiry: 0 0 0 0
> DESC CFG Error: 0 0 0 0
> DATA Underrun: 0 0 0 0
> DELIM Underrun: 0 0 0 0
> TX-Pkts-All: 666651 0 0 7717
> TX-Bytes-All: 816440297 0 0 633824
> hw-put-tx-buf: 952507 0 0 5766
> hw-tx-start: 0 0 0 0
> hw-tx-proc-desc: 0 0 0 0
> TX-Failed: 0 0 0 0
> txq-memory-address: f6bc1df0 f6bc1e8c f6bc1d54 f6bc1cb8
> axq-qnum: 2 3 1 0
> axq-depth: 2 0 0 0
> axq-ampdu_depth: 2 0 0 0
> axq-stopped 1 0 0 0
> tx-in-progress 0 0 0 0
> pending-frames 123 0 0 0
> txq_headidx: 3 0 0 6
> txq_tailidx: 3 0 0 6
> axq_q empty: 1 1 1 1
> axq_acq empty: 0 1 1 1
> txq_fifo[0] empty: 1 1 1 1
> txq_fifo[1] empty: 0 1 1 1
> txq_fifo[2] empty: 0 1 1 1
> txq_fifo[3] empty: 1 1 1 1
> txq_fifo[4] empty: 1 1 1 1
> txq_fifo[5] empty: 1 1 1 1
> txq_fifo[6] empty: 1 1 1 1
> txq_fifo[7] empty: 1 1 1 1
> txq[2] first-ac: f3da7a00 sched: 1
> first-tid: f3da73c8 sched: 1 paused: 0
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* [ath9k-devel] Debugging very slow ath9k AP performance
2012-04-05 23:19 ` Ben Greear
@ 2012-04-06 1:13 ` Ben Greear
0 siblings, 0 replies; 3+ messages in thread
From: Ben Greear @ 2012-04-06 1:13 UTC (permalink / raw)
To: ath9k-devel
On 04/05/2012 04:19 PM, Ben Greear wrote:
> On 04/05/2012 04:12 PM, Ben Greear wrote:
>> I am seeing very slow performance when I have around 100
>> stations connected to an AP (ath9k on both ends).
>>
>> It seems like the station side is doing fine, but on the
>> AP side, it appears there are always lots of pending frames
>> and it is only transmitting about 100 pkts per second if my stats
>> are correct.
>>
>> Kernel is 3.3.1+ with the troublesome ath9k patch reverted.
>>
>> I would be greatful for any pointers as to what might be
>> causing this slowdown.
>
> Hrm, just noticed dmesg is full of these messages:
>
> ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7658178
> ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7658178
> net_ratelimit: 33 callbacks suppressed
> ieee80211 wiphy0: dropped TX filtered frame, queue_len=0 PS=0 @7671545
>
> Will have to go figure out what that means...
Ok, I think the reason is just that the channel was too crowded.
Signal and noise and 'quality' were good..but way too many retries
and failed retries. Seems the AP has more issues than the client
for whatever reason, but moving to a different channel made it all
better again.
Seems like I do this to myself every few months...hopefully I'll
figure it out before spamming the list next time.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-04-06 1:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-05 23:12 [ath9k-devel] Debugging very slow ath9k AP performance Ben Greear
2012-04-05 23:19 ` Ben Greear
2012-04-06 1:13 ` Ben Greear
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.