From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Thu, 05 Apr 2012 18:13:59 -0700 Subject: [ath9k-devel] Debugging very slow ath9k AP performance In-Reply-To: <4F7E288F.9060306@candelatech.com> References: <4F7E26DD.6020602@candelatech.com> <4F7E288F.9060306@candelatech.com> Message-ID: <4F7E4357.6080608@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 Candela Technologies Inc http://www.candelatech.com