[ath9k-devel] persistent 5% packet loss with ath9k

[ath9k-devel] persistent 5% packet loss with ath9k

[Benjamin LaHaise]

Hello all,

I'm getting a persistent 5% packet loss with ath9k.  The card is a D-Link 
DWA-552 (see below for lspci -vvv results).  The link is to an 802.11n access 
point on the other side of the house, and iwconfig shows some count for 
Tx excessiv retries.  The catch is that using an Intel 802.11n card from 
the same location doesn't result in any significant packet loss (<1%).  
Any ideas?  I'm currently running 3.1.0-rc9+, but I see the same results 
with Fedora 15 kernels (2.6.38.6-26.rc1.fc15.x86_64 and 
2.6.40.6-0.fc15.x86_64@least, haven't tested any other kernels).  Note 
that I'm living in a rural area, and there is nothing else using the 2.4GHz 
spectrum around here, so 116ms ping times are quite unexpected and seem to 
point to a problem with ath9k.


		-ben
ping -c 200 -s 3000 x.x.x.x
...
--- x.x.x.x ping statistics ---
200 packets transmitted, 190 received, 5% packet loss, time 199200ms
rtt min/avg/max/mdev = 2.173/6.923/116.171/8.855 ms


wlan1     IEEE 802.11bgn  ESSID:"test3"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:xx:xx:xx:xx:xx   
          Bit Rate=48 Mb/s   Tx-Power=27 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=41/70  Signal level=-69 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:73  Invalid misc:62   Missed beacon:0


09:01.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
        Subsystem: D-Link System Inc DWA-552 802.11n Xtreme N Desktop Adapter (rev A1)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 168, Cache Line Size: 256 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory@fbef0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [40] #80 [0000]
        Kernel driver in use: ath9k
        Kernel modules: ath9k

ath9k config options:
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m
CONFIG_ATH9K_PCI=y
CONFIG_ATH9K_AHB=y
CONFIG_ATH9K_DEBUGFS=y
CONFIG_ATH9K_RATE_CONTROL=y
# CONFIG_ATH9K_HTC is not set

[ath9k-devel] disable_ani workaround -- was Re: persistent 5% packet loss with ath9k

[Benjamin LaHaise]

On Fri, Oct 14, 2011 at 11:29:40AM -0400, Benjamin LaHaise wrote:
...
> 2.6.40.6-0.fc15.x86_64 at least, haven't tested any other kernels).  Note 
> that I'm living in a rural area, and there is nothing else using the 2.4GHz 
> spectrum around here, so 116ms ping times are quite unexpected and seem to 
> point to a problem with ath9k.
...

Caleb Hearon pointed me at the "Network stalls every 30 seconds" thread 
from back in June which contains the suggestion of doing:

	echo >/sys/kernel/debug/ieee80211/phy0/ath9k/disable_ani 1

This fixes the immediate packet loss problem for me.  There still seem to be 
some issues with the first few packets of a large ping getting lost (during 
ARP it would seem), and DHCP takes a long time to complete when ath9k is 
initially brought up.

Is anyone working on a fix for the ANI problem?

		-ben