* poor performance with ath5k; reverting to ath_pci @ 2009-01-14 5:03 Glenn Burkhardt 2009-01-14 13:30 ` Nick Kossifidis 0 siblings, 1 reply; 19+ messages in thread From: Glenn Burkhardt @ 2009-01-14 5:03 UTC (permalink / raw) To: linux-wireless I just upgraded my system to Suse 11.1, and it installed the ath5k driver. I started having trouble with network access, and found that the response time to the wireless router in my house was lousy: glenn@DepotRd:~> ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the ath_pci driver. The results were much better: glenn@DepotRd:~> ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms The card I have is the Netgear WG311T, which reports with PCI ID 0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)". I'd be happy to try to help figure out why the response time is so bad with the ath5k driver, but I'm completely new to this code set. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-14 5:03 poor performance with ath5k; reverting to ath_pci Glenn Burkhardt @ 2009-01-14 13:30 ` Nick Kossifidis 2009-01-15 22:34 ` Glenn Burkhardt 0 siblings, 1 reply; 19+ messages in thread From: Nick Kossifidis @ 2009-01-14 13:30 UTC (permalink / raw) To: Glenn Burkhardt; +Cc: linux-wireless 2009/1/14 Glenn Burkhardt <gbburkhardt@verizon.net>: > I just upgraded my system to Suse 11.1, and it installed the ath5k driver. I > started having trouble with network access, and found that the response time > to the wireless router in my house was lousy: > > glenn@DepotRd:~> ping 192.168.2.1 > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms > > So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the ath_pci > driver. The results were much better: > > glenn@DepotRd:~> ping 192.168.2.1 > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms > > The card I have is the Netgear WG311T, which reports with PCI ID > 0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros AR5001X+ > Wireless Network Adapter (rev 01)". > > I'd be happy to try to help figure out why the response time is so bad with > the ath5k driver, but I'm completely new to this code set. Can you please post the dmesg output from when ath5k loads ? -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-14 13:30 ` Nick Kossifidis @ 2009-01-15 22:34 ` Glenn Burkhardt 2009-01-16 15:33 ` Bob Copeland 0 siblings, 1 reply; 19+ messages in thread From: Glenn Burkhardt @ 2009-01-15 22:34 UTC (permalink / raw) To: Nick Kossifidis; +Cc: linux-wireless On Wednesday 14 January 2009 08:30:03 Nick Kossifidis wrote: > 2009/1/14 Glenn Burkhardt <gbburkhardt@verizon.net>: > > I just upgraded my system to Suse 11.1, and it installed the ath5k > > driver. I started having trouble with network access, and found that the > > response time to the wireless router in my house was lousy: > > > > glenn@DepotRd:~> ping 192.168.2.1 > > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1233 ms > > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1901 ms > > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1550 ms > > > > So I pulled the madwifi-0.9.4-1.src.rpm, and re-configured to use the > > ath_pci driver. The results were much better: > > > > glenn@DepotRd:~> ping 192.168.2.1 > > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.493 ms > > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.485 ms > > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.501 ms > > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.518 ms > > > > The card I have is the Netgear WG311T, which reports with PCI ID > > 0x168c:0x0013, and in the log as "Atheros Communications Inc. Atheros > > AR5001X+ Wireless Network Adapter (rev 01)". > > > > I'd be happy to try to help figure out why the response time is so bad > > with the ath5k driver, but I'm completely new to this code set. > > Can you please post the dmesg output from when ath5k loads ? With ath_pci driver: glenn@DepotRd:~> ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.974 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.946 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.964 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.39 ms 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.964 ms 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=0.956 ms 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=0.948 ms 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.963 ms 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.957 ms 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=1.71 ms 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=3.62 ms 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.958 ms ^C --- 192.168.2.1 ping statistics --- 12 packets transmitted, 12 received, 0% packet loss, time 11043ms rtt min/avg/max/mdev = 0.946/1.279/3.624/0.744 ms glenn@DepotRd:~> iwconfig lo no wireless extensions. wifi0 no wireless extensions. ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331" Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:DF:A9:93:31 Bit Rate:54 Mb/s Tx-Power:15 dBm Sensitivity=1/1 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=25/70 Signal level=-70 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth0 no wireless extensions. Shortly thereafter, with ath5k loaded: DepotRd:/home/gbb-suse # modprobe ath5k DepotRd:/home/gbb-suse # /etc/init.d/network restart Shutting down network interfaces: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) No configuration found for eth0 Nevertheless the interface will be shut down. done wlan0 device: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) done Shutting down service network . . . . . . . . . done Hint: you may set mandatory devices in /etc/sysconfig/network/config Setting up network interfaces: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) No configuration found for eth0 unused wlan0 device: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) wlan0 warning: WPA configured but may be unsupported wlan0 warning: by this device wlan0 starting wpa_supplicant wlan0 Starting DHCP4 client. . . . . . . . wlan0 DHCP4 continues in background waiting Setting up service network . . . . . . . . . . done DepotRd:/home/gbb-suse # ping 192.168.2.1 connect: Network is unreachable DepotRd:/home/gbb-suse # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:62 errors:0 dropped:0 overruns:0 frame:0 TX packets:62 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4028 (3.9 Kb) TX bytes:4028 (3.9 Kb) wlan0 Link encap:Ethernet HWaddr 00:0F:B5:1D:93:2B inet addr:192.168.2.3 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wmaster0 Link encap:UNSPEC HWaddr 00-0F- B5-1D-93-2B-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) DepotRd:/home/gbb-suse # ping 192.168.2.1 connect: Network is unreachable DepotRd:/home/gbb-suse # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=18.1 ms 64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=4.25 ms 64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=8.36 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=4.24 ms 64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=10.1 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=6.25 ms 64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=5.95 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=7.60 ms 64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=5.36 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=7.49 ms 64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=6.14 ms 64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=1.06 ms 64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=6.89 ms 64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=6.74 ms 64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=0.750 ms RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wmaster0 Link encap:UNSPEC HWaddr 00-0F- B5-1D-93-2B-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) DepotRd:/home/gbb-suse # ping 192.168.2.1 connect: Network is unreachable DepotRd:/home/gbb-suse # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=18.1 ms 64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=4.25 ms 64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=8.36 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=4.24 ms 64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=10.1 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=6.25 ms 64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=5.95 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=7.60 ms 64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=5.36 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=7.49 ms 64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=6.14 ms 64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=1.06 ms 64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=6.89 ms 64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=6.74 ms 64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=0.750 ms 64 bytes from 192.168.2.1: icmp_seq=49 ttl=64 time=6.25 ms 64 bytes from 192.168.2.1: icmp_seq=50 ttl=64 time=5.38 ms 64 bytes from 192.168.2.1: icmp_seq=51 ttl=64 time=0.734 ms 64 bytes from 192.168.2.1: icmp_seq=52 ttl=64 time=6.47 ms ping: sendmsg: Network is unreachable ^C --- 192.168.2.1 ping statistics --- 53 packets transmitted, 19 received, 64% packet loss, time 52164ms rtt min/avg/max/mdev = 0.734/6.228/18.178/3.726 ms DepotRd:/home/gbb-suse # emacs /var/log/messages & [1] 2236 DepotRd:/home/gbb-suse # iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331" Mode:Managed Frequency:2.437 GHz Access Point: 00:1C:DF:A9:93:31 Bit Rate=54 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:713A-E283-4CAA-0D17-911E-A88E-B3AC-8C88-E5B3- AE6C-0923-FC80-5AF4-444F-08EB-4D2E [2] Security mode:open Power Management:off Link Quality=37/100 Signal level:-66 dBm Noise level=-90 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Output from dmesg: NET: Registered protocol family 10 lo: Disabled Privacy Extensions agpgart-sis 0000:00:00.0: AGP 3.5 bridge agpgart-sis 0000:00:00.0: putting AGP V3 device into 8x mode nvidia 0000:01:00.0: putting AGP V3 device into 8x mode NET: Registered protocol family 17 ath0: no IPv6 routers present bootsplash: status on console 0 changed to on ath_pci 0000:00:07.0: PCI INT A disabled ath_pci: driver unloaded ath_rate_sample: unloaded wlan: driver unloaded ath_hal: driver unloaded ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ath5k_pci 0000:00:07.0: registered as 'phy0' phy0: Selected rate control algorithm 'pid' ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43) ath5k phy0: RF2112A 2GHz radio found (0x46) ADDRCONF(NETDEV_UP): wlan0: link is not ready ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: authenticate with AP 00:1c:df:a9:93:31 wlan0: authenticated wlan0: associate with AP 00:1c:df:a9:93:31 wlan0: RX AssocResp from 00:1c:df:a9:93:31 (capab=0x411 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready padlock: VIA PadLock not detected. wlan0: no IPv6 routers present ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-15 22:34 ` Glenn Burkhardt @ 2009-01-16 15:33 ` Bob Copeland 2009-01-21 3:38 ` Glenn Burkhardt 2009-01-22 2:58 ` Glenn Burkhardt 0 siblings, 2 replies; 19+ messages in thread From: Bob Copeland @ 2009-01-16 15:33 UTC (permalink / raw) To: Glenn Burkhardt; +Cc: Nick Kossifidis, linux-wireless On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt <gbburkhardt@verizon.net> wrote: > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > ath5k_pci 0000:00:07.0: registered as 'phy0' > phy0: Selected rate control algorithm 'pid' Can you change the rate control algorithm to minstrel and retry? -- Bob Copeland %% www.bobcopeland.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-16 15:33 ` Bob Copeland @ 2009-01-21 3:38 ` Glenn Burkhardt 2009-01-21 15:14 ` John W. Linville 2009-01-22 2:58 ` Glenn Burkhardt 1 sibling, 1 reply; 19+ messages in thread From: Glenn Burkhardt @ 2009-01-21 3:38 UTC (permalink / raw) To: Bob Copeland; +Cc: Nick Kossifidis, linux-wireless On Friday 16 January 2009 10:33:13 Bob Copeland wrote: > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt > > <gbburkhardt@verizon.net> wrote: > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > ath5k_pci 0000:00:07.0: registered as 'phy0' > > phy0: Selected rate control algorithm 'pid' > > Can you change the rate control algorithm to minstrel and retry? I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have changed besides the rate control code. It looks like minstrel and pid give about the same result, a bit worse that the ath_pci driver right now. Performance seems to vary from day to day. I'll experiment some more, and switch transmission channels. I'm not getting the really poor performance with ath5k right now. I haven't looked yet - is there a way to switch to 'pid' rate control without rebuilding the kernel? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 3:38 ` Glenn Burkhardt @ 2009-01-21 15:14 ` John W. Linville 2009-01-21 18:22 ` Stefanik Gábor 0 siblings, 1 reply; 19+ messages in thread From: John W. Linville @ 2009-01-21 15:14 UTC (permalink / raw) To: Glenn Burkhardt; +Cc: Bob Copeland, Nick Kossifidis, linux-wireless On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote: > On Friday 16 January 2009 10:33:13 Bob Copeland wrote: > > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt > > > > <gbburkhardt@verizon.net> wrote: > > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > > ath5k_pci 0000:00:07.0: registered as 'phy0' > > > phy0: Selected rate control algorithm 'pid' > > > > Can you change the rate control algorithm to minstrel and retry? > > I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The > kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have > changed besides the rate control code. > > It looks like minstrel and pid give about the same result, a bit worse that > the ath_pci driver right now. Performance seems to vary from day to day. > I'll experiment some more, and switch transmission channels. I'm not getting > the really poor performance with ath5k right now. > > I haven't looked yet - is there a way to switch to 'pid' rate control without > rebuilding the kernel? If you configure your kernel to include multiple rate control algorithms then you can use the 'ieee80211_default_rc_algo' module option for mac80211. Of course, changing that only works if you rmmod/insmod mac80211. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 15:14 ` John W. Linville @ 2009-01-21 18:22 ` Stefanik Gábor 2009-01-21 19:11 ` John W. Linville 0 siblings, 1 reply; 19+ messages in thread From: Stefanik Gábor @ 2009-01-21 18:22 UTC (permalink / raw) To: John W. Linville Cc: Glenn Burkhardt, Bob Copeland, Nick Kossifidis, linux-wireless On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville <linville@tuxdriver.com> wrote: > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote: >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote: >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt >> > >> > <gbburkhardt@verizon.net> wrote: >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 >> > > ath5k_pci 0000:00:07.0: registered as 'phy0' >> > > phy0: Selected rate control algorithm 'pid' >> > >> > Can you change the rate control algorithm to minstrel and retry? >> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. The >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more could have >> changed besides the rate control code. >> >> It looks like minstrel and pid give about the same result, a bit worse that >> the ath_pci driver right now. Performance seems to vary from day to day. >> I'll experiment some more, and switch transmission channels. I'm not getting >> the really poor performance with ath5k right now. >> >> I haven't looked yet - is there a way to switch to 'pid' rate control without >> rebuilding the kernel? > > If you configure your kernel to include multiple rate control > algorithms then you can use the 'ieee80211_default_rc_algo' module > option for mac80211. Of course, changing that only works if you > rmmod/insmod mac80211. > > John Judging from this, is it really a good idea to hide pid behind EMBEDDED? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 18:22 ` Stefanik Gábor @ 2009-01-21 19:11 ` John W. Linville 2009-01-21 19:33 ` Stefanik Gábor 0 siblings, 1 reply; 19+ messages in thread From: John W. Linville @ 2009-01-21 19:11 UTC (permalink / raw) To: Stefanik Gábor Cc: Glenn Burkhardt, Bob Copeland, Nick Kossifidis, linux-wireless On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote: > On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville > <linville@tuxdriver.com> wrote: > > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote: > >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote: > >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt > >> > > >> > <gbburkhardt@verizon.net> wrote: > >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IR= Q 18 > >> > > ath5k_pci 0000:00:07.0: registered as 'phy0' > >> > > phy0: Selected rate control algorithm 'pid' > >> > > >> > Can you change the rate control algorithm to minstrel and retry? > >> > >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. T= he > >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more coul= d have > >> changed besides the rate control code. > >> > >> It looks like minstrel and pid give about the same result, a bit w= orse that > >> the ath_pci driver right now. Performance seems to vary from day = to day. > >> I'll experiment some more, and switch transmission channels. I'm = not getting > >> the really poor performance with ath5k right now. > >> > >> I haven't looked yet - is there a way to switch to 'pid' rate cont= rol without > >> rebuilding the kernel? > > > > If you configure your kernel to include multiple rate control > > algorithms then you can use the 'ieee80211_default_rc_algo' module > > option for mac80211. Of course, changing that only works if you > > rmmod/insmod mac80211. > > > > John >=20 > Judging from this, is it really a good idea to hide pid behind EMBEDD= ED? I've been wondering about that myself. I'm inclined to think no. John --=20 John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 19:11 ` John W. Linville @ 2009-01-21 19:33 ` Stefanik Gábor 2009-01-21 19:34 ` John W. Linville 2009-01-22 4:32 ` Nick Kossifidis 0 siblings, 2 replies; 19+ messages in thread From: Stefanik Gábor @ 2009-01-21 19:33 UTC (permalink / raw) To: John W. Linville Cc: Glenn Burkhardt, Bob Copeland, Nick Kossifidis, linux-wireless On Wed, Jan 21, 2009 at 8:11 PM, John W. Linville <linville@tuxdriver.com> wrote: > On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote: >> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville >> <linville@tuxdriver.com> wrote: >> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote: >> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote: >> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt >> >> > >> >> > <gbburkhardt@verizon.net> wrote: >> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 >> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0' >> >> > > phy0: Selected rate control algorithm 'pid' >> >> > >> >> > Can you change the rate control algorithm to minstrel and retry= ? >> >> >> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k. = The >> >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more cou= ld have >> >> changed besides the rate control code. >> >> >> >> It looks like minstrel and pid give about the same result, a bit = worse that >> >> the ath_pci driver right now. Performance seems to vary from day= to day. >> >> I'll experiment some more, and switch transmission channels. I'm= not getting >> >> the really poor performance with ath5k right now. >> >> >> >> I haven't looked yet - is there a way to switch to 'pid' rate con= trol without >> >> rebuilding the kernel? >> > >> > If you configure your kernel to include multiple rate control >> > algorithms then you can use the 'ieee80211_default_rc_algo' module >> > option for mac80211. Of course, changing that only works if you >> > rmmod/insmod mac80211. >> > >> > John >> >> Judging from this, is it really a good idea to hide pid behind EMBED= DED? > > I've been wondering about that myself. I'm inclined to think no. > > John I think EMBEDDED is for options that replace full-featured Linux components with dumbed-down, "low-profile" equivalents (like SLOB) - PID vs. minstrel is more like SLAB vs. SLUB. G=E1bor --=20 Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 19:33 ` Stefanik Gábor @ 2009-01-21 19:34 ` John W. Linville 2009-01-22 4:32 ` Nick Kossifidis 1 sibling, 0 replies; 19+ messages in thread From: John W. Linville @ 2009-01-21 19:34 UTC (permalink / raw) To: Stefanik Gábor Cc: Glenn Burkhardt, Bob Copeland, Nick Kossifidis, linux-wireless On Wed, Jan 21, 2009 at 08:33:01PM +0100, Stefanik G=E1bor wrote: > On Wed, Jan 21, 2009 at 8:11 PM, John W. Linville > <linville@tuxdriver.com> wrote: > > On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote: > >> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville > >> <linville@tuxdriver.com> wrote: > >> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote: > >> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote: > >> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt > >> >> > > >> >> > <gbburkhardt@verizon.net> wrote: > >> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 > >> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0' > >> >> > > phy0: Selected rate control algorithm 'pid' > >> >> > > >> >> > Can you change the rate control algorithm to minstrel and ret= ry? > >> >> > >> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k.= The > >> >> kernel for Suse 11.1 is 2.6.27.7-9. But that means that more c= ould have > >> >> changed besides the rate control code. > >> >> > >> >> It looks like minstrel and pid give about the same result, a bi= t worse that > >> >> the ath_pci driver right now. Performance seems to vary from d= ay to day. > >> >> I'll experiment some more, and switch transmission channels. I= 'm not getting > >> >> the really poor performance with ath5k right now. > >> >> > >> >> I haven't looked yet - is there a way to switch to 'pid' rate c= ontrol without > >> >> rebuilding the kernel? > >> > > >> > If you configure your kernel to include multiple rate control > >> > algorithms then you can use the 'ieee80211_default_rc_algo' modu= le > >> > option for mac80211. Of course, changing that only works if you > >> > rmmod/insmod mac80211. > >> > > >> > John > >> > >> Judging from this, is it really a good idea to hide pid behind EMB= EDDED? > > > > I've been wondering about that myself. I'm inclined to think no. > > > > John >=20 > I think EMBEDDED is for options that replace full-featured Linux > components with dumbed-down, "low-profile" equivalents (like SLOB) - > PID vs. minstrel is more like SLAB vs. SLUB. Patches welcome. Bonus points if you find a way to switch algorithms without module unloading and/or to pick different algorithms for different interfaces. John --=20 John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-21 19:33 ` Stefanik Gábor 2009-01-21 19:34 ` John W. Linville @ 2009-01-22 4:32 ` Nick Kossifidis 2009-01-22 13:49 ` John W. Linville 1 sibling, 1 reply; 19+ messages in thread From: Nick Kossifidis @ 2009-01-22 4:32 UTC (permalink / raw) To: Stefanik Gábor Cc: John W. Linville, Glenn Burkhardt, Bob Copeland, linux-wireless 2009/1/21 Stefanik G=C3=A1bor <netrolller.3d@gmail.com>: > > I think EMBEDDED is for options that replace full-featured Linux > components with dumbed-down, "low-profile" equivalents (like SLOB) - > PID vs. minstrel is more like SLAB vs. SLUB. > > G=C3=A1bor > Minstrell performs very well even on embedded devices, i don't think it's that heavy compared to pid. --=20 GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 4:32 ` Nick Kossifidis @ 2009-01-22 13:49 ` John W. Linville 2009-01-22 14:04 ` Johannes Berg 0 siblings, 1 reply; 19+ messages in thread From: John W. Linville @ 2009-01-22 13:49 UTC (permalink / raw) To: Nick Kossifidis Cc: Stefanik Gábor, Glenn Burkhardt, Bob Copeland, linux-wireless On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote: > 2009/1/21 Stefanik G=E1bor <netrolller.3d@gmail.com>: > > > > I think EMBEDDED is for options that replace full-featured Linux > > components with dumbed-down, "low-profile" equivalents (like SLOB) = - > > PID vs. minstrel is more like SLAB vs. SLUB. > > > > G=E1bor > > >=20 > Minstrell performs very well even on embedded devices, i don't think > it's that heavy compared to pid. I think his point was that people should be able to select multiple algorithms without having to select EMBEDDED. John --=20 John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 13:49 ` John W. Linville @ 2009-01-22 14:04 ` Johannes Berg 2009-01-22 14:17 ` John W. Linville 0 siblings, 1 reply; 19+ messages in thread From: Johannes Berg @ 2009-01-22 14:04 UTC (permalink / raw) To: John W. Linville Cc: Nick Kossifidis, Stefanik Gábor, Glenn Burkhardt, Bob Copeland, linux-wireless [-- Attachment #1: Type: text/plain, Size: 922 bytes --] On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote: > On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote: > > 2009/1/21 Stefanik Gábor <netrolller.3d@gmail.com>: > > > > > > I think EMBEDDED is for options that replace full-featured Linux > > > components with dumbed-down, "low-profile" equivalents (like SLOB) - > > > PID vs. minstrel is more like SLAB vs. SLUB. > > > > > > Gábor > > > > > > > Minstrell performs very well even on embedded devices, i don't think > > it's that heavy compared to pid. > > I think his point was that people should be able to select multiple > algorithms without having to select EMBEDDED. The reason it was originally under EMBEDDED is that this allows you to turn off _all_ algorithms, and that breaks, but might be desirable if you have a system where you know you're using iwlagn or ath9k only which have their own algorithms. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 14:04 ` Johannes Berg @ 2009-01-22 14:17 ` John W. Linville 2009-01-22 14:45 ` Stefanik Gábor 0 siblings, 1 reply; 19+ messages in thread From: John W. Linville @ 2009-01-22 14:17 UTC (permalink / raw) To: Johannes Berg Cc: Nick Kossifidis, Stefanik Gábor, Glenn Burkhardt, Bob Copeland, linux-wireless On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote: > On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote: > > On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote: > > > 2009/1/21 Stefanik G=E1bor <netrolller.3d@gmail.com>: > > > > > > > > I think EMBEDDED is for options that replace full-featured Linu= x > > > > components with dumbed-down, "low-profile" equivalents (like SL= OB) - > > > > PID vs. minstrel is more like SLAB vs. SLUB. > > > > > > > > G=E1bor > > > > > > >=20 > > > Minstrell performs very well even on embedded devices, i don't th= ink > > > it's that heavy compared to pid. > >=20 > > I think his point was that people should be able to select multiple > > algorithms without having to select EMBEDDED. >=20 > The reason it was originally under EMBEDDED is that this allows you t= o > turn off _all_ algorithms, and that breaks, but might be desirable if > you have a system where you know you're using iwlagn or ath9k only wh= ich > have their own algorithms. I see. But currently it limits you to only one generic algorithm, the one chosen as the default. I don't think that was really the intent? John --=20 John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 14:17 ` John W. Linville @ 2009-01-22 14:45 ` Stefanik Gábor 2009-01-22 15:18 ` John W. Linville 0 siblings, 1 reply; 19+ messages in thread From: Stefanik Gábor @ 2009-01-22 14:45 UTC (permalink / raw) To: John W. Linville Cc: Johannes Berg, Nick Kossifidis, Glenn Burkhardt, Bob Copeland, linux-wireless On Thu, Jan 22, 2009 at 3:17 PM, John W. Linville <linville@tuxdriver.com> wrote: > On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote: >> On Thu, 2009-01-22 at 08:49 -0500, John W. Linville wrote: >> > On Thu, Jan 22, 2009 at 06:32:55AM +0200, Nick Kossifidis wrote: >> > > 2009/1/21 Stefanik G=E1bor <netrolller.3d@gmail.com>: >> > > > >> > > > I think EMBEDDED is for options that replace full-featured Lin= ux >> > > > components with dumbed-down, "low-profile" equivalents (like S= LOB) - >> > > > PID vs. minstrel is more like SLAB vs. SLUB. >> > > > >> > > > G=E1bor >> > > > >> > > >> > > Minstrell performs very well even on embedded devices, i don't t= hink >> > > it's that heavy compared to pid. >> > >> > I think his point was that people should be able to select multipl= e >> > algorithms without having to select EMBEDDED. >> >> The reason it was originally under EMBEDDED is that this allows you = to >> turn off _all_ algorithms, and that breaks, but might be desirable i= f >> you have a system where you know you're using iwlagn or ath9k only w= hich >> have their own algorithms. > > I see. But currently it limits you to only one generic algorithm, th= e > one chosen as the default. I don't think that was really the intent? > I think RC_NONE should depend on embedded, but not the chooser itself. --=20 Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 14:45 ` Stefanik Gábor @ 2009-01-22 15:18 ` John W. Linville 0 siblings, 0 replies; 19+ messages in thread From: John W. Linville @ 2009-01-22 15:18 UTC (permalink / raw) To: Stefanik Gábor Cc: Johannes Berg, Nick Kossifidis, Glenn Burkhardt, Bob Copeland, linux-wireless On Thu, Jan 22, 2009 at 03:45:58PM +0100, Stefanik G=E1bor wrote: > On Thu, Jan 22, 2009 at 3:17 PM, John W. Linville > <linville@tuxdriver.com> wrote: > > On Thu, Jan 22, 2009 at 03:04:35PM +0100, Johannes Berg wrote: > >> The reason it was originally under EMBEDDED is that this allows yo= u to > >> turn off _all_ algorithms, and that breaks, but might be desirable= if > >> you have a system where you know you're using iwlagn or ath9k only= which > >> have their own algorithms. > > > > I see. But currently it limits you to only one generic algorithm, = the > > one chosen as the default. I don't think that was really the inten= t? > > >=20 > I think RC_NONE should depend on embedded, but not the chooser itself= =2E That makes sense to me. John --=20 John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-16 15:33 ` Bob Copeland 2009-01-21 3:38 ` Glenn Burkhardt @ 2009-01-22 2:58 ` Glenn Burkhardt 2009-01-23 7:31 ` Nick Kossifidis 1 sibling, 1 reply; 19+ messages in thread From: Glenn Burkhardt @ 2009-01-22 2:58 UTC (permalink / raw) To: Bob Copeland; +Cc: Nick Kossifidis, linux-wireless On Friday 16 January 2009 10:33:13 Bob Copeland wrote: > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt > > <gbburkhardt@verizon.net> wrote: > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > > ath5k_pci 0000:00:07.0: registered as 'phy0' > > phy0: Selected rate control algorithm 'pid' > > Can you change the rate control algorithm to minstrel and retry? I'll have to say that performance is worse with minstrel than pid rate control. I used Channel 2 on the router, and: ath_pci: DepotRd:/home/gbb-suse/wireless # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=5.82 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.32 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.967 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.954 ms 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.970 ms 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=1.14 ms 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1.32 ms 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.981 ms 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.961 ms 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.88 ms 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.962 ms 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.894 ms 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=0.991 ms 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=0.968 ms 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=0.978 ms 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=1.10 ms 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=0.999 ms 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=0.998 ms DepotRd:/home/gbb-suse/wireless # iwconfig lo no wireless extensions. eth0 no wireless extensions. wifi0 no wireless extensions. ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331" Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 Bit Rate:36 Mb/s Tx-Power:15 dBm Sensitivity=1/1 Retry:off RTS thr:off Fragment thr:off Encryption key:FA2D-087E-61EF-D860-2E7D-46C9-AF65-CA4C Security mode:restricted Power Management:off Link Quality=37/70 Signal level=-59 dBm Noise level=-96 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 ath5k with pid: DepotRd:/home/gbb-suse/linux-2.6.28.1 # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1729 ms 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=2320 ms 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=2050 ms 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=1402 ms 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1323 ms 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1151 ms 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=608 ms 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=1134 ms 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=1100 ms 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=356 ms 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=164 ms 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=423 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=20 ttl=64 time=407 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=1086 ms 64 bytes from 192.168.2.1: icmp_seq=24 ttl=64 time=1442 ms DepotRd:~ # iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331" Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 Bit Rate=54 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:E854-5075-1208-1225-D46B-46E6-CB2C-B627-DA3D-788E- F50E-7351-DDE0-C111-E9A5-1FB7 [2] Security mode:open Power Management:off Link Quality=53/100 Signal level:-69 dBm Noise level=-103 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 ath5k with minstrel dmesg | egrep 'ath|phy' BIOS-provided physical RAM map: Setting physnode_map array to node 0 for pfns: ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ath5k_pci 0000:00:07.0: registered as 'phy0' phy0: Selected rate control algorithm 'minstrel' ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43) ath5k phy0: RF2112B 2GHz radio found (0x46) DepotRd:# ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=13159 ms ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=40968 ms 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=42986 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=41983 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=42860 ms DepotRd:~ # iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331" Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 Bit Rate=54 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:1193-9C46-9CB0-B2EE-99CA-EA37-7EB4-1B62-9475-B834- AE70-AA4F-B4A5-B303-3D51-4244 [2] Security mode:open Power Management:off Link Quality=56/100 Signal level:-67 dBm Noise level=-103 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-22 2:58 ` Glenn Burkhardt @ 2009-01-23 7:31 ` Nick Kossifidis 2009-02-03 2:36 ` Glenn Burkhardt 0 siblings, 1 reply; 19+ messages in thread From: Nick Kossifidis @ 2009-01-23 7:31 UTC (permalink / raw) To: Glenn Burkhardt; +Cc: Bob Copeland, linux-wireless 2009/1/22 Glenn Burkhardt <gbburkhardt@verizon.net>: > On Friday 16 January 2009 10:33:13 Bob Copeland wrote: >> On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt >> >> <gbburkhardt@verizon.net> wrote: >> > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 >> > ath5k_pci 0000:00:07.0: registered as 'phy0' >> > phy0: Selected rate control algorithm 'pid' >> >> Can you change the rate control algorithm to minstrel and retry? > > I'll have to say that performance is worse with minstrel than pid rate > control. I used Channel 2 on the router, and: > > ath_pci: > DepotRd:/home/gbb-suse/wireless # ping 192.168.2.1 > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=5.82 ms > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.32 ms > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.967 ms > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.954 ms > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.970 ms > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=1.14 ms > 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1.32 ms > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.981 ms > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.961 ms > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.88 ms > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.962 ms > 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.894 ms > 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=0.991 ms > 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=0.968 ms > 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=0.978 ms > 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=1.10 ms > 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=0.999 ms > 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=0.998 ms > DepotRd:/home/gbb-suse/wireless # iwconfig > lo no wireless extensions. > > eth0 no wireless extensions. > > wifi0 no wireless extensions. > > ath0 IEEE 802.11g ESSID:"Belkin_N_Wireless_A99331" > Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 > Bit Rate:36 Mb/s Tx-Power:15 dBm Sensitivity=1/1 > Retry:off RTS thr:off Fragment thr:off > Encryption key:FA2D-087E-61EF-D860-2E7D-46C9-AF65-CA4C Security > mode:restricted > Power Management:off > Link Quality=37/70 Signal level=-59 dBm Noise level=-96 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > ath5k with pid: > > DepotRd:/home/gbb-suse/linux-2.6.28.1 # ping 192.168.2.1 > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1729 ms > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=2320 ms > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=2050 ms > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=1402 ms > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1323 ms > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1151 ms > 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=608 ms > 64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=1134 ms > 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=1100 ms > 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=356 ms > 64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=164 ms > 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=423 ms > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=20 ttl=64 time=407 ms > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=1086 ms > 64 bytes from 192.168.2.1: icmp_seq=24 ttl=64 time=1442 ms > DepotRd:~ # iwconfig > lo no wireless extensions. > > eth0 no wireless extensions. > > wmaster0 no wireless extensions. > > wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331" > Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 > Bit Rate=54 Mb/s Tx-Power=27 dBm > Retry min limit:7 RTS thr:off Fragment thr=2352 B > Encryption key:E854-5075-1208-1225-D46B-46E6-CB2C-B627-DA3D-788E- > F50E-7351-DDE0-C111-E9A5-1FB7 [2] Security mode:open > Power Management:off > Link Quality=53/100 Signal level:-69 dBm Noise level=-103 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > > ath5k with minstrel > > dmesg | egrep 'ath|phy' > BIOS-provided physical RAM map: > Setting physnode_map array to node 0 for pfns: > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > ath5k_pci 0000:00:07.0: registered as 'phy0' > phy0: Selected rate control algorithm 'minstrel' > ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43) > ath5k phy0: RF2112B 2GHz radio found (0x46) > > DepotRd:# ping 192.168.2.1 > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=13159 ms > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=40968 ms > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=42986 ms > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=41983 ms > ping: sendmsg: Network is unreachable > 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=42860 ms > DepotRd:~ # iwconfig > lo no wireless extensions. > > eth0 no wireless extensions. > > wmaster0 no wireless extensions. > > wlan0 IEEE 802.11bg ESSID:"Belkin_N_Wireless_A99331" > Mode:Managed Frequency:2.417 GHz Access Point: 00:1C:DF:A9:93:31 > Bit Rate=54 Mb/s Tx-Power=27 dBm > Retry min limit:7 RTS thr:off Fragment thr=2352 B > Encryption key:1193-9C46-9CB0-B2EE-99CA-EA37-7EB4-1B62-9475-B834- > AE70-AA4F-B4A5-B303-3D51-4244 [2] Security mode:open > Power Management:off > Link Quality=56/100 Signal level:-67 dBm Noise level=-103 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > O.K. so both algorithms have overestimated the rate, madwifi with minstrel sets it to 36M and both pid an minstrel on ath5k/mac80211 set it to 54M. This results packet corruption and packet loss. Please try locking the rate to 18M - 36M and check the performance again (also an iperf udp test would be very usefull) to see if this is only a problem with the algorithm or a more generic problem. -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: poor performance with ath5k; reverting to ath_pci 2009-01-23 7:31 ` Nick Kossifidis @ 2009-02-03 2:36 ` Glenn Burkhardt 0 siblings, 0 replies; 19+ messages in thread From: Glenn Burkhardt @ 2009-02-03 2:36 UTC (permalink / raw) To: Nick Kossifidis; +Cc: linux-wireless > O.K. so both algorithms have overestimated the rate, madwifi with > minstrel sets it to 36M and both pid an minstrel on ath5k/mac80211 set > it to 54M. This results packet corruption and packet loss. Please try > locking the rate to 18M - 36M and check the performance again (also an > iperf udp test would be very usefull) to see if this is only a problem > with the algorithm or a more generic problem. It doesn't seem to be the rate selection. I switched to channel 2 again, and the version of ath5k that came with Suse 11.1 didn't connect to my router at all. The ath_pci driver I built did, with roughly millisecond ping round trips. The ath_pci driver changed the bit rate to 18 Mb/s; ath5k reported using 5.5 Mb/s, but ping was never successful. I also built a kernel from the wireless testing repository ( 2.6.29-rc3-wl-9- pae), and that driver was able to connect initially, although with a slow response rate: PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=3086 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=2925 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=3293 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=3986 ms 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=4018 ms 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=3030 ms ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable It reported the bit rate to be 54 Mb/s; I tried turning it down to as low as 6 Mb/s, but then it didn't work at all. This last test was using 'minstrel' rate control; it doesn't seem that 'pid' is a selectable option in the kernel configuration for 'wireless testing'. I'll try to get some more data with 'iperf'. I have a couple of other machines in the house that I can use. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2009-02-03 4:24 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-14 5:03 poor performance with ath5k; reverting to ath_pci Glenn Burkhardt 2009-01-14 13:30 ` Nick Kossifidis 2009-01-15 22:34 ` Glenn Burkhardt 2009-01-16 15:33 ` Bob Copeland 2009-01-21 3:38 ` Glenn Burkhardt 2009-01-21 15:14 ` John W. Linville 2009-01-21 18:22 ` Stefanik Gábor 2009-01-21 19:11 ` John W. Linville 2009-01-21 19:33 ` Stefanik Gábor 2009-01-21 19:34 ` John W. Linville 2009-01-22 4:32 ` Nick Kossifidis 2009-01-22 13:49 ` John W. Linville 2009-01-22 14:04 ` Johannes Berg 2009-01-22 14:17 ` John W. Linville 2009-01-22 14:45 ` Stefanik Gábor 2009-01-22 15:18 ` John W. Linville 2009-01-22 2:58 ` Glenn Burkhardt 2009-01-23 7:31 ` Nick Kossifidis 2009-02-03 2:36 ` Glenn Burkhardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).