#2403: Slow performance of MADWIFI driver over the past 6 months
--------------------------------+-------------------------------------------
Reporter: warts...@yahoo.com | Type: defect
Status: new | Priority: minor
Component: madwifi: driver | Version: trunk
Keywords: | Patch_attached: 0
Pending: 0 |
--------------------------------+-------------------------------------------
The madwifi driver used to work so well on my Ubuntu laptop's AR5212 chip.
Now I get very slow and erratic performance with both the MADWIFI driver
as well as the ath5k driver (the later of which has never worked well for
me).
I am currently running Ubuntu's 2.6.31-21-generic kernel with the ath5k
driver blacklisted. I successfully compiled the MADWIFI svn r4128 driver
for it and it is associated with my access point:
IEEE 802.11g ESSID:"default" Nickname:""
Mode:Managed Frequency:2.427 GHz Access Point:
00:50:18:0C:E9:8E
Bit Rate=11 Mb/s Tx-Power:17 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=48/70 Signal level=-47 dBm Noise level=-95 dBm
Rx invalid nwid:650 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
athstats says:
3092 tx management frames
10 tx failed due to too many retries
657 long on-chip tx retries
2922 tx frames with no ack marked
10 tx frames with an alternate rate
803 rx failed due to bad CRC
13 PHY errors
13 CCK restart
2543 periodic calibrations
rssi of last rcv: 50
233 switched default/rx antenna
Antenna profile:
[1] tx 129 rx 16402
[2] tx 1540 rx 10116
Here is the results of pinging my AP:
r...@thinkpad:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=4694 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=3788 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=3087 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=2181 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=4655 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=4986 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=4528 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=7388 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=7923 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=7333 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=6839 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=6658 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=4029 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=3151 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=2328 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=1348 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=2975 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=2179 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=1479 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=1398 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=500 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=114 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=35.5 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=467 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=798 ms
64 bytes from 192.168.0.1: icmp_seq=26 ttl=64 time=3.44 ms
64 bytes from 192.168.0.1: icmp_seq=27 ttl=64 time=742 ms
64 bytes from 192.168.0.1: icmp_seq=28 ttl=64 time=151 ms
64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=1301 ms
64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=398 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=215 ms
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=33.4 ms
64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=55.4 ms
64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=79.7 ms
64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=919 ms
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=22.1 ms
64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=44.8 ms
64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=578 ms
64 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=90.3 ms
64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=625 ms
64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=751 ms
64 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=263 ms
^C
--- 192.168.0.1 ping statistics ---
43 packets transmitted, 42 received, 2% packet loss, time 47107ms
rtt min/avg/max/mdev = 3.445/2170.249/7923.993/2386.252 ms, pipe 5
I am also seeing this in dmsg:
[ 44.906808] ath_pci 0000:02:02.0: PCI INT A -> Link[LNKF] -> GSI 11
(level, low) -> IRQ 11
[ 45.210731] MadWifi: ath_attach: Switching rfkill capability off.
[ 45.400966] wifi0: Atheros AR5213 chip found (MAC 5.6, PHY 2112 4.1, 5
GHz Radio 1.7 2 GHz Radio 2.3)
[ 45.442977] ath_pci: wifi0: Atheros 5212: mem=0xd0200000, irq=11
...
[ 701.941721] ath0: unknown SIOCSIWAUTH flag 12
[ 717.388730] ath0: unknown SIOCSIWAUTH flag 12
[ 765.855390] ath0: unknown SIOCSIWAUTH flag 12
[ 781.412976] ath0: unknown SIOCSIWAUTH flag 12
[ 794.185527] ath0: unknown SIOCSIWAUTH flag 12
[ 876.003170] ath0: unknown SIOCSIWAUTH flag 12
[ 932.133737] ath0: unknown SIOCSIWAUTH flag 12
[ 947.499238] ath0: unknown SIOCSIWAUTH flag 12
I am trying turning off bursting, CTS, and FastFrame as suggested
elsewhere but see no significant improvement.
This same computer can boot into M$-Windows and WIFI works perfectly, just
as the MADWIFI driver used to work for me some 6-months ago on older
kernels and earlier versions of the Ubuntu OS.
I check and there are no other signals on my AP's channel (4), but there
are some weak signals on channel 6 some 20db less strong.
I am running Ubuntu Karmic, fully updated, and have tried several of their
kernels including the Linux-Wireless "compat" one, as well as my own with
similar results. I just got
Is there any other information I can provide that can help troubleshoot
the problem?
--
Ticket URL: <http://madwifi-project.org/ticket/2403>
madwifi-project.org <http://madwifi-project.org/>
Multiband Atheros Driver for Wireless Fidelity
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Madwifi-tickets mailing list
Madwifi-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
