* [ath9k-devel] Zyxel NWD-170n badly slow
@ 2009-07-17 16:03 Andrej Podzimek
2009-07-17 16:30 ` Luis R. Rodriguez
0 siblings, 1 reply; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-17 16:03 UTC (permalink / raw)
To: ath9k-devel
Hello,
I have a question regarding the 802.11n transfer rates. My 802.11n WiFi card associated with a 802.11n router is badly slow. The maximum data rates are only about 3 MB/s (24 Mb/s), exactly the same as when a 802.11g client is used. What could this be caused by? Some details follow.
The network:
Zyxel NBG-420N (router, firmware version: V3.60(AMO.5) | 02/28/2009)
Zyxel NWD-170N (PCMCIA adapter)
A radius server providing EAP-TLS (connected via ethernet)
Client's kernel: 2.6.30.1 vanilla
This is what lspci says:
02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
This is what I found in dmesg:
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
ath9k 0000:02:00.0: enabling device (0000 -> 0002)
ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) -> IRQ 5
phy1: Selected rate control algorithm 'ath9k_rate_control'
cfg80211: Calling CRDA for country: AM
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
Registered led device: ath9k-phy1::radio
Registered led device: ath9k-phy1::assoc
Registered led device: ath9k-phy1::tx
Registered led device: ath9k-phy1::rx
phy1: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0780000, irq=5
The regulatory domain is a weird issue, too. iw reg set can sometimes change it, but sometimes it doesn't take any action (and no error is reported). When it does something, this is what it looks like:
cfg80211: Calling CRDA for country: CZ
cfg80211: Regulatory domain changed to country: CZ
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
I found out that the hardware combination inside the NWD-170N WiFi card is not on the hardware compatibility list. (http://linuxwireless.org/en/users/Drivers/ath9k#supported_chipsets) Could this be the reason why only 802.11g, but not 802.11n is supported?
The transfer rate shown in iwconfig is always either 1 Mb/s or 11 Mb/s, although the connection speed about 24 Mb/s.)
wlan0 IEEE 802.11bgn ESSID:"Net2"
Mode:Managed Frequency:2.437 GHz Access Point: 00:23:F8:22:AA:A6
Bit Rate=11 Mb/s Tx-Power=20 dBm
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** [2] Security mode:open
Power Management:off
Link Quality=66/70 Signal level=-44 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Scan output from iwconfig:
Cell 02 - Address: 00:23:F8:22:AA:A6
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=70/70 Signal level=-39 dBm
Encryption key:on
ESSID:"Net2"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=0000000c5c8d0180
Extra: Last beacon: 16ms ago
IE: Unknown: 00044E657432
IE: Unknown: 010882848B960C121824
IE: Unknown: 030106
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : 802.1x
IE: Unknown: 2A0100
IE: Unknown: 32043048606C
IE: Unknown: DD1E00904C334C101B0000000000000000000000000000000000000000000000
IE: Unknown: 2D1A4C101B0000000000000000000000000000000000000000000000
IE: Unknown: DD1A00904C3406001B00000000000000000000000000000000000000
IE: Unknown: 3D1606001B00000000000000000000000000000000000000
IE: Unknown: DD0900037F01010000FF7F
IE: Unknown: DD0A00037F04010000000000
Scan output from iw:
BSS 00:23:f8:22:aa:a6 (on wlan0)
TSF: 53096900774 usec (0d, 14:44:56)
freq: 2437
beacon interval: 100
capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
signal: -52.00 dBm
SSID: Net2
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Paramater set: channel 6
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: IEEE 802.1X
* Capabilities: (0x0000)
ERP: <no flags>
Extended supported rates: 24.0 36.0 48.0 54.0
This is what iw list says:
Wiphy phy1
Band 1:
HT capabilities: 0x104e
* 20/40 MHz operation
* SM PS disabled
* 40 MHz short GI
* max A-MSDU len 3839
* DSSS/CCK 40 MHz
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0006 (8 usec)
HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00
HT TX/RX MCS rate indexes supported:
MCS index 0
MCS index 1
MCS index 2
MCS index 3
MCS index 4
MCS index 5
MCS index 6
MCS index 7
MCS index 8
MCS index 9
MCS index 10
MCS index 11
MCS index 12
MCS index 13
MCS index 14
MCS index 15
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Bitrates:
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
The connection works just fine, as far as 802.11g is concerned, but I just didn't find a way to switch to 802.11n transfer rates. Could anybody give me a piece of advice, please? Is there a patch or GIT version I should try?
Best regards,
Andrej Podzimek
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 16:03 [ath9k-devel] Zyxel NWD-170n badly slow Andrej Podzimek
@ 2009-07-17 16:30 ` Luis R. Rodriguez
2009-07-17 17:31 ` Andrej Podzimek
0 siblings, 1 reply; 12+ messages in thread
From: Luis R. Rodriguez @ 2009-07-17 16:30 UTC (permalink / raw)
To: ath9k-devel
On Fri, Jul 17, 2009 at 9:03 AM, Andrej Podzimek<andrej@podzimek.org> wrote:
> Hello,
>
> I have a question regarding the 802.11n transfer rates. My 802.11n WiFi card associated with a 802.11n router is badly slow. The maximum data rates are only about 3 MB/s (24 Mb/s), exactly the same as when a 802.11g client is used. What could this be caused by?
This could be an interoperability issue with a specific Access Point.
> Some details follow.
>
> The network:
>
> ? ? ? ?Zyxel NBG-420N (router, firmware version: V3.60(AMO.5) | 02/28/2009)
This helps, thanks for reporting this, not sure if our team will have
this AP to test on, we will see.
> ? ? ? ?Zyxel NWD-170N (PCMCIA adapter)
> ? ? ? ?A radius server providing EAP-TLS (connected via ethernet)
> ? ? ? ?Client's kernel: 2.6.30.1 vanilla
>
> This is what lspci says:
>
> ? ? ? ?02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
>
> This is what I found in dmesg:
>
> ? ? ? ?pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
> ? ? ? ?pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
> ? ? ? ?ath9k 0000:02:00.0: enabling device (0000 -> 0002)
> ? ? ? ?ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) -> IRQ 5
> ? ? ? ?phy1: Selected rate control algorithm 'ath9k_rate_control'
> ? ? ? ?cfg80211: Calling CRDA for country: AM
> ? ? ? ?cfg80211: Current regulatory domain intersected:
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? ? ? ? ?(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ?Registered led device: ath9k-phy1::radio
> ? ? ? ?Registered led device: ath9k-phy1::assoc
> ? ? ? ?Registered led device: ath9k-phy1::tx
> ? ? ? ?Registered led device: ath9k-phy1::rx
> ? ? ? ?phy1: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0780000, irq=5
>
> The regulatory domain is a weird issue, too. iw reg set can sometimes change it, but sometimes it doesn't take any action (and no error is reported). When it does something, this is what it looks like:
>
> ? ? ? ?cfg80211: Calling CRDA for country: CZ
> ? ? ? ?cfg80211: Regulatory domain changed to country: CZ
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> ? ? ? ? ? ? ? ?(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
Do you have CONFIG_WIRELESS_OLD_REGULATORY set? Are you using an
ieee80211_regdom module parameter? You can disable these. Anyway --
you should not need to set your regulatory domain manually at all for
ath9k devicesl, the card already has regulatory domain information
embedded on the EEPROM and this is used by the card to get regulatory
domain information for the card. For ath9k, since it has EEPROM
regulatory information we trust it and keep that information. Further
user input for ath9k devices will only restrict the device further,
never add more capabilities. So you should be OK with the default
values the card has unless you want to help compliance further.
> I found out that the hardware combination inside the NWD-170N WiFi card is not on the hardware compatibility list. (http://linuxwireless.org/en/users/Drivers/ath9k#supported_chipsets) Could this be the reason why only 802.11g, but not 802.11n is supported?
No, it just means that card was never added to the list, please feel
free to add it.
> The transfer rate shown in iwconfig is always either 1 Mb/s or 11 Mb/s, although the connection speed about 24 Mb/s.)
iwconfig does not report MCS rates, iwconfig uses wireless extensions
and wireless-extensions is not getting extended any further. The new
wireless API is through cfg80211, the userspace interface for this
nl80211. nl80211 based applications should be used now. iw is such
application [1], and it seems you already have it. Please read its
documentation and learn to use that over iwconfig, the documentation
has replacement commands.
Although iw does understand MCS rates ath9k is currently not reporting
the right MCS rate index to the kernel, this is due to how ath9k rate
control algorithm is implemented -- this needs to be fixed.
To review what rates your card is using you can enable
CONFIG_ATH9K_DEBUG and then read the debugfs rcstat file. For
documentation on this please read:
http://wireless.kernel.org/en/users/Drivers/ath9k/debug
[1] http://wireless.kernel.org/en/users/Documentation/iw
> ? ? ? ?wlan0 ? ? IEEE 802.11bgn ?ESSID:"Net2"
> ? ? ? ? ? ? ? ? ?Mode:Managed ?Frequency:2.437 GHz ?Access Point: 00:23:F8:22:AA:A6
> ? ? ? ? ? ? ? ? ?Bit Rate=11 Mb/s ? Tx-Power=20 dBm
> ? ? ? ? ? ? ? ? ?Retry min limit:7 ? RTS thr:off ? Fragment thr:off
> ? ? ? ? ? ? ? ? ?Encryption key:****-****-****-****-****-****-****-**** [2] ? Security mode:open
> ? ? ? ? ? ? ? ? ?Power Management:off
> ? ? ? ? ? ? ? ? ?Link Quality=66/70 ?Signal level=-44 dBm
> ? ? ? ? ? ? ? ? ?Rx invalid nwid:0 ?Rx invalid crypt:0 ?Rx invalid frag:0
> ? ? ? ? ? ? ? ? ?Tx excessive retries:0 ?Invalid misc:0 ? Missed beacon:0
>
> Scan output from iwconfig:
>
> ? ? ? ?Cell 02 - Address: 00:23:F8:22:AA:A6
> ? ? ? ? ? ? ? ? ?Channel:6
> ? ? ? ? ? ? ? ? ?Frequency:2.437 GHz (Channel 6)
> ? ? ? ? ? ? ? ? ?Quality=70/70 ?Signal level=-39 dBm
> ? ? ? ? ? ? ? ? ?Encryption key:on
> ? ? ? ? ? ? ? ? ?ESSID:"Net2"
> ? ? ? ? ? ? ? ? ?Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?9 Mb/s; 12 Mb/s; 18 Mb/s
> ? ? ? ? ? ? ? ? ?Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
> ? ? ? ? ? ? ? ? ?Mode:Master
> ? ? ? ? ? ? ? ? ?Extra:tsf=0000000c5c8d0180
> ? ? ? ? ? ? ? ? ?Extra: Last beacon: 16ms ago
> ? ? ? ? ? ? ? ? ?IE: Unknown: 00044E657432
> ? ? ? ? ? ? ? ? ?IE: Unknown: 010882848B960C121824
> ? ? ? ? ? ? ? ? ?IE: Unknown: 030106
> ? ? ? ? ? ? ? ? ?IE: IEEE 802.11i/WPA2 Version 1
> ? ? ? ? ? ? ? ? ? ? ?Group Cipher : CCMP
> ? ? ? ? ? ? ? ? ? ? ?Pairwise Ciphers (1) : CCMP
> ? ? ? ? ? ? ? ? ? ? ?Authentication Suites (1) : 802.1x
> ? ? ? ? ? ? ? ? ?IE: Unknown: 2A0100
> ? ? ? ? ? ? ? ? ?IE: Unknown: 32043048606C
> ? ? ? ? ? ? ? ? ?IE: Unknown: DD1E00904C334C101B0000000000000000000000000000000000000000000000
> ? ? ? ? ? ? ? ? ?IE: Unknown: 2D1A4C101B0000000000000000000000000000000000000000000000
> ? ? ? ? ? ? ? ? ?IE: Unknown: DD1A00904C3406001B00000000000000000000000000000000000000
> ? ? ? ? ? ? ? ? ?IE: Unknown: 3D1606001B00000000000000000000000000000000000000
> ? ? ? ? ? ? ? ? ?IE: Unknown: DD0900037F01010000FF7F
> ? ? ? ? ? ? ? ? ?IE: Unknown: DD0A00037F04010000000000
>
> Scan output from iw:
>
> ? ? ? ?BSS 00:23:f8:22:aa:a6 (on wlan0)
> ? ? ? ?TSF: 53096900774 usec (0d, 14:44:56)
> ? ? ? ?freq: 2437
> ? ? ? ?beacon interval: 100
> ? ? ? ?capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
> ? ? ? ?signal: -52.00 dBm
> ? ? ? ?SSID: Net2
> ? ? ? ?Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
> ? ? ? ?DS Paramater set: channel 6
> ? ? ? ?RSN: ? ? * Version: 1
> ? ? ? ? ? ? ? ? * Group cipher: CCMP
> ? ? ? ? ? ? ? ? * Pairwise ciphers: CCMP
> ? ? ? ? ? ? ? ? * Authentication suites: IEEE 802.1X
> ? ? ? ? ? ? ? ? * Capabilities: (0x0000)
> ? ? ? ?ERP: <no flags>
> ? ? ? ?Extended supported rates: 24.0 36.0 48.0 54.0
>
> This is what iw list says:
>
> ? ? ? ?Wiphy phy1
> ? ? ? ? ? ? ? ?Band 1:
> ? ? ? ? ? ? ? ? ? ? ? ?HT capabilities: 0x104e
> ? ? ? ? ? ? ? ? ? ? ? ?* 20/40 MHz operation
> ? ? ? ? ? ? ? ? ? ? ? ?* SM PS disabled
> ? ? ? ? ? ? ? ? ? ? ? ?* 40 MHz short GI
> ? ? ? ? ? ? ? ? ? ? ? ?* max A-MSDU len 3839
> ? ? ? ? ? ? ? ? ? ? ? ?* DSSS/CCK 40 MHz
> ? ? ? ? ? ? ? ?HT A-MPDU factor: 0x0003 (65535 bytes)
> ? ? ? ? ? ? ? ?HT A-MPDU density: 0x0006 (8 usec)
> ? ? ? ? ? ? ? ?HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00
> ? ? ? ? ? ? ? ?HT TX/RX MCS rate indexes supported:
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 0
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 1
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 2
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 3
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 4
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 5
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 6
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 7
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 8
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 9
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 10
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 11
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 12
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 13
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 14
> ? ? ? ? ? ? ? ? ? ? ? ?MCS index 15
> ? ? ? ? ? ? ? ?Frequencies:
> ? ? ? ? ? ? ? ? ? ? ? ?* 2412 MHz [1] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2417 MHz [2] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2422 MHz [3] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2427 MHz [4] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2432 MHz [5] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2437 MHz [6] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2442 MHz [7] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2447 MHz [8] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2452 MHz [9] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2457 MHz [10] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2462 MHz [11] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2467 MHz [12] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2472 MHz [13] (20.0 dBm)
> ? ? ? ? ? ? ? ? ? ? ? ?* 2484 MHz [14] (disabled)
> ? ? ? ? ? ? ? ?Bitrates:
> ? ? ? ? ? ? ? ? ? ? ? ?* 1.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 2.0 Mbps (short preamble supported)
> ? ? ? ? ? ? ? ? ? ? ? ?* 5.5 Mbps (short preamble supported)
> ? ? ? ? ? ? ? ? ? ? ? ?* 11.0 Mbps (short preamble supported)
> ? ? ? ? ? ? ? ? ? ? ? ?* 6.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 9.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 12.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 18.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 24.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 36.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 48.0 Mbps
> ? ? ? ? ? ? ? ? ? ? ? ?* 54.0 Mbps
> ? ? ? ?max # scan SSIDs: 4
> ? ? ? ?Supported interface modes:
> ? ? ? ? ? ? ? ?* IBSS
> ? ? ? ? ? ? ? ?* managed
> ? ? ? ? ? ? ? ?* AP
> ? ? ? ? ? ? ? ?* AP/VLAN
> ? ? ? ? ? ? ? ?* monitor
> ? ? ? ? ? ? ? ?* mesh point
>
> The connection works just fine, as far as 802.11g is concerned, but I just didn't find a way to switch to 802.11n transfer rates.
This could be an interoperability issue. You can try the
wireless-testing git tree directly [1] or you can try just the
wireless drivers by using compat-wireless [2]. For further details on
how to get the latest ath9k driver please read:
http://wireless.kernel.org/en/users/Drivers/ath9k#Get_the_latest_ath9k_driver
> Could anybody give me a piece of advice, please? Is there a patch or GIT version I should try?
If you want to stay on bleeding edge to help test ath9k patches you
can always use wireless-testing directly, and git-pull every week for
new changes. If you rather not compile your entire kernel you can just
use compat-wireless -- that is updated daily automatically from
wireless-testing.
Chances are this is an interoperability issue. Another user had
reported an issue with his AP with 11n rates on AR5416 but our team
has yet to test it. The information you have provided is great and can
help zero in on the issue.
I recommend to check if your AP has any firmware upgrades available,
and to also try out the latest ath9k driver updates.
Luis
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 16:30 ` Luis R. Rodriguez
@ 2009-07-17 17:31 ` Andrej Podzimek
2009-07-17 17:59 ` Luis R. Rodriguez
0 siblings, 1 reply; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-17 17:31 UTC (permalink / raw)
To: ath9k-devel
Hello,
>> I have a question regarding the 802.11n transfer rates. My 802.11n WiFi card associated with a 802.11n router is badly slow. The maximum data rates are only about 3 MB/s (24 Mb/s), exactly the same as when a 802.11g client is used. What could this be caused by?
>
> This could be an interoperability issue with a specific Access Point.
Yes, but these are two Zyxel devices, both recommended by the manufacturer as a good combination for 802.11n networking...
> Do you have CONFIG_WIRELESS_OLD_REGULATORY set?
It was on when I started testing this card. Then I recompiled the kernel with this option set to off. It didn't really change anything.
> Are you using an ieee80211_regdom module parameter?
The ath9k module I use does not accept such a parameter. The same applies to the mac80211 module. Maybe it's not in the vanilla kernel yet? Will try something bleeding-edge ASAP (compat-wireless).
> Anyway --
> you should not need to set your regulatory domain manually at all for
> ath9k devicesl, the card already has regulatory domain information
> embedded on the EEPROM and this is used by the card to get regulatory
> domain information for the card.
I used the ath_info utility with an old ath5k card to change the regdomain. I usually buy WiFi hardware on eBay from USA or Hong Kong, so it's necessary to switch to the ETSI regdomain. (Some people say it's 0x30, others say it's 0x37. Both of them seem to work.)
However, ath_info says "MAC revision 0x3fb7 is not supported!" when used with my Zyxel PCMCIA card, so there's probably no way to change the value in the EEPROM.
The problem is that iw reg set only takes effect once per system lifetime. It's obviously not designed for USB, PCMCIA or other removable WiFi adapters. Consequently, when you need to reset the device (plug/unplug, reload the module), there is no way to restore the regdomain settings without rebooting. Any subsequent re-initializations of the device use the original value from EEPROM (which is correct) and the kernel does not switch the device to the new regdomain configured using iw (which is wrong). (Anyway, this doesn't seem to be an ath9k problem.)
> For ath9k, since it has EEPROM
> regulatory information we trust it and keep that information. Further
> user input for ath9k devices will only restrict the device further,
> never add more capabilities. So you should be OK with the default
> values the card has unless you want to help compliance further.
If I am not mistaken, it seems that changing the regulatory domain *did* add some capabilities:
Before:
cfg80211: Calling CRDA for country: AM
cfg80211: Regulatory domain changed to country: AM
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
After:
cfg80211: Calling CRDA for country: CZ
cfg80211: Regulatory domain changed to country: CZ
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
There are more channels and higher output power is allowed.
Anyway, maybe I'm wrong and the card's capabilities are limited by an intersection of some built-in country-specific hardware limitations and the regulatory domain. If so, relaxing the regulatory domain won't (necessarily) relax the whole intersection of rules...
> The new
> wireless API is through cfg80211, the userspace interface for this
> nl80211. nl80211 based applications should be used now. iw is such
> application [1], and it seems you already have it. Please read its
> documentation and learn to use that over iwconfig, the documentation
> has replacement commands.
Yes, I know it has 802.11n channel "width" settings, mesh network settings and other new features. However, I just hoped there would be something like "switch 802.11n ON" somewhere... ;-) However, this problem is probably much more complicated. (It seems that 802.11n support cannot be explicitly switched on and off, so the solution is not that simple.)
> I recommend to check if your AP has any firmware upgrades available,
> and to also try out the latest ath9k driver updates.
OK, will try the latest ath9k. The AP has the latest firmware, of course. That's the first thing I checked.
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 17:31 ` Andrej Podzimek
@ 2009-07-17 17:59 ` Luis R. Rodriguez
2009-07-17 20:54 ` Andrej Podzimek
0 siblings, 1 reply; 12+ messages in thread
From: Luis R. Rodriguez @ 2009-07-17 17:59 UTC (permalink / raw)
To: ath9k-devel
On Fri, Jul 17, 2009 at 10:31 AM, Andrej Podzimek<andrej@podzimek.org> wrote:
> Hello,
>
>>> I have a question regarding the 802.11n transfer rates. My 802.11n WiFi
>>> card associated with a 802.11n router is badly slow. The maximum data rates
>>> are only about 3 MB/s (24 Mb/s), exactly the same as when a 802.11g client
>>> is used. What could this be caused by?
>>
>> This could be an interoperability issue with a specific Access Point.
>
> Yes, but these are two Zyxel devices, both recommended by the manufacturer
> as a good combination for 802.11n networking...
Heh yeah point taken, still my point being that maybe the firmware for
the AP is a bit old and we haven't tested against it.
>> Do you have CONFIG_WIRELESS_OLD_REGULATORY set?
>
> It was on when I started testing this card. Then I recompiled the kernel
> with this option set to off. It didn't really change anything.
Was just checking.
>> Are you using an ieee80211_regdom module parameter?
>
> The ath9k module I use does not accept such a parameter. The same applies to
> the mac80211 module. Maybe it's not in the vanilla kernel yet? Will try
> something bleeding-edge ASAP (compat-wireless).
Was just asking to see if you used it to understand better how your
cfg80211 is coming up and with what parameters. I do not want you to
use it but it is available through the cfg80211 module. Just ignore
this then.
>> Anyway --
>> you should not need to set your regulatory domain manually at all for
>> ath9k devicesl, the card already has regulatory domain information
>> embedded on the EEPROM and this is used by the card to get regulatory
>> domain information for the card.
>
> I used the ath_info utility with an old ath5k card to change the regdomain.
Just so you know, if you do such a thing don't be surprised if you
loose support. The device EEPROM should be left as-is.
> I usually buy WiFi hardware on eBay from USA or Hong Kong, so it's necessary
> to switch to the ETSI regdomain. (Some people say it's 0x30, others say it's
> 0x37. Both of them seem to work.)
This is not something you should be mucking with because of the lack
of documentation of implications of such action, you are disregarding
calibration information, I'd advise to just set it back. If you want
to change regulatory domains use the upstream Linux wireless drivers
as-is and then do use the properly supported methods to change
regulatory domains. That is: use iw.
> However, ath_info says "MAC revision 0x3fb7 is not supported!" when used
> with my Zyxel PCMCIA card, so there's probably no way to change the value in
> the EEPROM.
EEPROM changes every few revisions... ath_info is for legacy
(802.11bg) devices. Writing to your device EEPROM can screw things up,
only manufacturers should be doing that as they then calibrate the
devices and ensure properly compliance.
> The problem is that iw reg set only takes effect once per system lifetime.
You mean upon bootup, yes. That can be fixed in cfg80211, but I
haven't had a chance to do that. But you should only need to set that
once unless you are pm-suspend'ing and then going to another country.
Anyway, as I said before for ath9k devices have regulatory information
on the EEPROM, you should not need to set anything when using ath9k
devices unless you want to help compliance further.
> It's obviously not designed for USB, PCMCIA or other removable WiFi
> adapters.
Driver regulatory hints are always trusted. If you have a card with no
regulatory information and you set your regulatory domain to "US" then
you obviously meant it. Plugging another device will get you the same
information. What there is no support yet for is suspending, flying to
another country and then setting the regulatory domain again to
something different.
> Consequently, when you need to reset the device (plug/unplug,
> reload the module), there is no way to restore the regdomain settings
> without rebooting.
No, if you try to set the regulatory domain twice for the same country
nothing will be done as there is no need to do anything as everything
was already done.
> Any subsequent re-initializations of the device use the
> original value from EEPROM (which is correct) and the kernel does not switch
> the device to the new regdomain configured using iw (which is wrong).
> (Anyway, this doesn't seem to be an ath9k problem.)
Driver regulatory hints are always trusted in cfg80211, but cfg80211
trusts the first device that is plugged in. We could do an
intersection for two devices, we have support for that, but we had
decided to go with the first plugged in device first. Either way your
device always gets its own driver regulatory hint, which is what
counts.
>> For ath9k, since it has EEPROM
>> regulatory information we trust it and keep that information. Further
>> user input for ath9k devices will only restrict the device further,
>> never add more capabilities. So you should be OK with the default
>> values the card has unless you want to help compliance further.
>
> If I am not mistaken, it seems that changing the regulatory domain *did* add
> some capabilities:
>
> Before:
> ? ? ? ?cfg80211: Calling CRDA for country: AM
> ? ? ? ?cfg80211: Regulatory domain changed to country: AM
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> ? ? ? ? ? ? ? ?(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
>
> After:
> ? ? ? ?cfg80211: Calling CRDA for country: CZ
> ? ? ? ?cfg80211: Regulatory domain changed to country: CZ
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> ? ? ? ? ? ? ? ?(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
>
> There are more channels and higher output power is allowed.
No, that is the regulatory domain information. To see the actual
channel information that gets stuck to a device use 'iw list'. Drivers
that have their own EEPROM and regulatory information always trust
that information first. User input is only used for those devices to
help compliance further, not to override it.
> Anyway, maybe I'm wrong and the card's capabilities are limited by an
> intersection of some built-in country-specific hardware limitations and the
> regulatory domain.
You are wrong, please read carefully.
You have no need to set the regulatory domain with ath9k devices
unless you want to enhance compliance.
>> The new
>> wireless API is through cfg80211, the userspace interface for this
>> nl80211. nl80211 based applications should be used now. iw is such
>> application [1], and it seems you already have it. Please read its
>> documentation and learn to use that over iwconfig, the documentation
>> has replacement commands.
>
> Yes, I know it has 802.11n channel "width" settings, mesh network settings
> and other new features. However, I just hoped there would be something like
> "switch 802.11n ON" somewhere... ;-) However, this problem is probably much
> more complicated. (It seems that 802.11n support cannot be explicitly
> switched on and off, so the solution is not that simple.)
The real reason for not supporting 11n with Wireless-extensions is we
came up with a better framework for wireless. Wireless-extensions was
designed with old wireless hardware in mind and is simply a developer
pain to work with. For more information please read:
http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions
>> I recommend to check if your AP has any firmware upgrades available,
>> and to also try out the latest ath9k driver updates.
>
> OK, will try the latest ath9k. The AP has the latest firmware, of course.
> That's the first thing I checked.
Great thanks.
Luis
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 17:59 ` Luis R. Rodriguez
@ 2009-07-17 20:54 ` Andrej Podzimek
2009-07-17 21:24 ` Luis R. Rodriguez
0 siblings, 1 reply; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-17 20:54 UTC (permalink / raw)
To: ath9k-devel
>>> Are you using an ieee80211_regdom module parameter?
>> The ath9k module I use does not accept such a parameter. The same applies to
>> the mac80211 module. Maybe it's not in the vanilla kernel yet? Will try
>> something bleeding-edge ASAP (compat-wireless).
>
> Was just asking to see if you used it to understand better how your
> cfg80211 is coming up and with what parameters. I do not want you to
> use it but it is available through the cfg80211 module. Just ignore
> this then.
I had cfg80211 compiled into the kernel, not as a module. That's why I could not find out what module is supposed to take that parameter.
I recompiled the kernel to get the cfg80211 module, which is necessary for compat-wireless anyway. Compiled and installed today's compat-wireless afterwards. Added this to modprobe.conf:
options cfg80211 ieee80211_regdom=CZ
The device initialization now looks like this:
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:02:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
cfg80211: Calling CRDA for country: CZ
ath9k 0000:02:00.0: enabling device (0000 -> 0002)
ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) -> IRQ 5
cfg80211: Regulatory domain changed to country: CZ
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
ath: EEPROM regdomain: 0x30
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: AM
ath: Regpair used: 0x30
phy0: Selected rate control algorithm 'ath9k_rate_control'
cfg80211: Calling CRDA for country: AM
cfg80211: Regulatory domain changed to country: AM
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
Registered led device: ath9k-phy0::radio
Registered led device: ath9k-phy0::assoc
Registered led device: ath9k-phy0::tx
Registered led device: ath9k-phy0::rx
phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0b80000, irq=5
Now this is how it worked:
WMM QoS off, 20 MHz channels: about 24 Mb/s, like 802.11g
WMM QoS off, 40 MHz channels: about 10 Mb/s, really bad
WMM QoS ON, 20 MHz channels: about 60 Mb/s
WMM QoS ON, 40 MHz channels: about 56 Mb/s, 60 Mb/s peaks
WMM QoS is just a checkbox in the router's web interface. ;-) I don't know what it exactly does. When I configured this WMM stuff with MadWifi and hostapd, there were at least 30 different settings, not just yes/no. I never thought WMM could influence transfer rates when one client talks to one AP. The checkbox probably does much more than just WMM.
I experimented with iw channel settings, especially HT20, HT40+ and HT40-. However, it either didn't influence the speed in any way, or killed the connection. (The latter is not surprising...) I don't know whether the AP uses HT40+ or HT40-. When wide channels are enabled on the AP, both settings work on the client.
To sum up, the current speed is better than 802.11g, but no better than Atheros' g+.
Maybe I should try the debugfs stuff to get more output data. Would that be helpful, or just loss of time?
There's one more problem I didn't mention. The router was bought here (Czech Republic) and conforms to ETSI, whereas the PCIMCIA card comes from the USA. They both conform to Draft 2.0, but it seems there's some strange compatibility issue.
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 20:54 ` Andrej Podzimek
@ 2009-07-17 21:24 ` Luis R. Rodriguez
2009-07-17 23:42 ` Andrej Podzimek
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Luis R. Rodriguez @ 2009-07-17 21:24 UTC (permalink / raw)
To: ath9k-devel
On Fri, Jul 17, 2009 at 1:54 PM, Andrej Podzimek<andrej@podzimek.org> wrote:
>>>> Are you using an ieee80211_regdom module parameter?
>>>
>>> The ath9k module I use does not accept such a parameter. The same applies
>>> to
>>> the mac80211 module. Maybe it's not in the vanilla kernel yet? Will try
>>> something bleeding-edge ASAP (compat-wireless).
>>
>> Was just asking to see if you used it to understand better how your
>> cfg80211 is coming up and with what parameters. I do not want you to
>> use it but it is available through the cfg80211 module. Just ignore
>> this then.
>
> I had cfg80211 compiled into the kernel, not as a module. That's why I could
> not find out what module is supposed to take that parameter.
>
> I recompiled the kernel to get the cfg80211 module, which is necessary for
> compat-wireless anyway. Compiled and installed today's compat-wireless
> afterwards. Added this to modprobe.conf:
>
> ? ? ? ?options cfg80211 ieee80211_regdom=CZ
ieee80211_regdom is the same thing as using 'iw reg set' but we will
eventually remove ieee80211_regdom module parameter. Please consider
abandoning it.
The reason why I asked if you were using it was to tell you to not use it.
> The device initialization now looks like this:
>
> ? ? ? ?pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot
> 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pci 0000:02:00.0: reg 10
> 32bit mmio: [0x000000-0x00ffff]
> ? ? ? ?cfg80211: Calling CRDA for country: CZ
> ? ? ? ?ath9k 0000:02:00.0: enabling device (0000 -> 0002)
> ? ? ? ?ath9k 0000:02:00.0: PCI INT A -> Link[LNKB] -> GSI 5 (level, low) ->
> IRQ 5
> ? ? ? ?cfg80211: Regulatory domain changed to country: CZ
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> ? ? ? ? ? ? ? ?(2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2301 mBm)
> ? ? ? ? ? ? ? ?(5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> ? ? ? ?ath: EEPROM regdomain: 0x30
> ? ? ? ?ath: EEPROM indicates we should expect a direct regpair map
> ? ? ? ?ath: Country alpha2 being used: AM
> ? ? ? ?ath: Regpair used: 0x30
> ? ? ? ?phy0: Selected rate control algorithm 'ath9k_rate_control'
> ? ? ? ?cfg80211: Calling CRDA for country: AM
> ? ? ? ?cfg80211: Regulatory domain changed to country: AM
> ? ? ? ? ? ? ? ?(start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> ? ? ? ? ? ? ? ?(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> ? ? ? ? ? ? ? ?(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ? ? ? ? ?(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> ? ? ? ?Registered led device: ath9k-phy0::radio
> ? ? ? ?Registered led device: ath9k-phy0::assoc
> ? ? ? ?Registered led device: ath9k-phy0::tx
> ? ? ? ?Registered led device: ath9k-phy0::rx
> ? ? ? ?phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81: mem=0xf0b80000,
> irq=5
As I explained before, the card's regulatory is always being
respected, whether you call this before or after does will not affect
ath9k. In other words all this conversation we've had about regulatory
is completely orthogonal to your issue.
> Now this is how it worked:
>
> ? ? ? ?WMM QoS off, 20 MHz channels: ? about 24 Mb/s, like 802.11g
> ? ? ? ?WMM QoS off, 40 MHz channels: ? about 10 Mb/s, really bad
> ? ? ? ?WMM QoS ?ON, 20 MHz channels: ? about 60 Mb/s
> ? ? ? ?WMM QoS ?ON, 40 MHz channels: ? about 56 Mb/s, 60 Mb/s peaks
Using what? iperf? TCP or UDP?
> WMM QoS is just a checkbox in the router's web interface. ;-)
I was under the impression 802.11n *requires QoS*, not sure why it
would let you disable it..
> I experimented with iw channel settings, especially HT20, HT40+ and HT40-.
> However, it either didn't influence the speed in any way, or killed the
> connection. (The latter is not surprising...) I don't know whether the AP
> uses HT40+ or HT40-. When wide channels are enabled on the AP, both settings
> work on the client.
Are you using 2.4 GHz or 5 GHz? What channel/freq are you on? How many
APs can you detect nearby and what channels are they on? Try to set
your AP to a channel far away from the others.
> To sum up, the current speed is better than 802.11g, but no better than
> Atheros' g+.
You should be able to do better than what you have. I'm not going to
defend 11n but you should realize IEEE-802.11n is being standardized,
Atheros turbo, or+ or whatever is not and will never get supported in
ath9k, and very likely also not in ath5k. The 11n drafts take into
account backward compatibility, and interference issues, I don't know
how g+ or whatever deals with this.
> Maybe I should try the debugfs stuff to get more output data. Would that be
> helpful, or just loss of time?
You can check the ath9k rcstat:
http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
Please provide the output of that file after a few quick tests. Reset
the counters by reloading ath9k if you want to compare against some
different environment.
> There's one more problem I didn't mention. The router was bought here (Czech
> Republic) and conforms to ETSI, whereas the PCIMCIA card comes from the USA.
> They both conform to Draft 2.0, but it seems there's some strange
> compatibility issue.
I think it should be possible to do achieve better throughput, keep in
mind we have a lot of patches pending to be merged to wireless-testing
(over 20), some of them may help. John is traveling right now so not
sure when he'll be able to merge them.
I have stuffed all pending patches into one file:
http://bombadil.infradead.org/~mcgrof/patches/all.patch
if you want to test using wireless-testing directly. Not sure if this
will apply to compat-wireless cleanly.
Luis
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 21:24 ` Luis R. Rodriguez
@ 2009-07-17 23:42 ` Andrej Podzimek
2009-07-17 23:46 ` Ashish Sharma
2009-07-25 13:50 ` Andrej Podzimek
2009-07-25 14:16 ` [ath9k-devel] Zyxel NWD-170n warning Andrej Podzimek
2 siblings, 1 reply; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-17 23:42 UTC (permalink / raw)
To: ath9k-devel
> ieee80211_regdom is the same thing as using 'iw reg set' but we will
> eventually remove ieee80211_regdom module parameter. Please consider
> abandoning it.
I removed the option from modprobe.conf. The initialization looks very similar. This appears instead of the CZ regdomain:
cfg80211: World regulatory domain updated:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
However, two problems appeared:
* spurious disconnections
No probe response from AP 00:23:f8:22:aa:a6 after 200ms, disconnecting.
* the card won't associate unless I set this manually:
iw dev wlan0 set channel 6 HT40-
> Using what? iperf? TCP or UDP?
This is a *good* question! Yes, iperf. I didn't consider trying UDP before. The results are surprising, to say the least.
TCP: 58 to 63 Mb/s
UDP: 1 Mb/s
This was measured during a transfer that took 30 seconds. I tried both IPv4 and IPv6. (Presumably, results were almost the same.)
The UDP problem does not seem to be caused by packet loss:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-30.0 sec 3.74 MBytes 1.05 Mbits/sec 0.777 ms 5/ 2675 (0.19%)
[ 3] 0.0-30.0 sec 1 datagrams received out-of-order
> I was under the impression 802.11n *requires QoS*, not sure why it
> would let you disable it..
Disabling QoS and enabling 40 MHz channels reduces the performance of 802.11g to about 10 Mb/s and the 802.11n adapter performs no better. When 40 MHz channels are disabled, 802.11g devices work normally (24 Mb/s) without QoS, but 802.11n devices only work at g speeds.
Simply put, disabling QoS probably disables 802.11n as well, although the web interface says it's enabled.
> Are you using 2.4 GHz or 5 GHz? What channel/freq are you on? How many
> APs can you detect nearby and what channels are they on? Try to set
> your AP to a channel far away from the others.
2.4 GHz.
There are mostly 3 visible APs on channels 1, 7 and 11. (Yes, that's quite a bad situation.) When I set automatic channel selection on the router, it sticks to channel 6. (I have never seen an automatic channel change.) All those visible APs are quite far away, below -75 dBm.
I also tried channels 4 and 13 with the client set to HT+ and HT- respectively, but the speed was about 80% of what I would get with the default channel 6. (I didn't measure this in detail, just a standard 10s test.) (UDP was a disaster again.)
> You should be able to do better than what you have. I'm not going to
> defend 11n but you should realize IEEE-802.11n is being standardized,
> Atheros turbo, or+ or whatever is not and will never get supported in
> ath9k, and very likely also not in ath5k.
This is *good* news.
(G+ is not supported.) && (Bandwidth exceeds 54 Mb/s.) => (802.11n works somehow.)
> You can check the ath9k rcstat:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
>
> Please provide the output of that file after a few quick tests. Reset
> the counters by reloading ath9k if you want to compare against some
> different environment.
Thanks for the info. I'll definitely try this tomorrow.
> I have stuffed all pending patches into one file:
>
> http://bombadil.infradead.org/~mcgrof/patches/all.patch
>
> if you want to test using wireless-testing directly. Not sure if this
> will apply to compat-wireless cleanly.
Yes, it will. Nothing rejected. I'm compiling that now and will report results.
BTW, I ran into this weird error when watching the data rate and signal quality with ksysguard:
BUG: scheduling while atomic: ksysguardd/6116/0x00000002
Modules linked in: aes_i586 aes_generic ath9k mac80211 ath cfg80211 rfkill_backport arc4 ecb ipv6 sco bnep l2cap bluetooth rng_core uinput ohci1394 ieee1394 tun usbhid dvb_usb_af9015 dvb_usb dvb_core ipw2200 libipw lib80211 8139too mii lp ppdev parport_pc parport uhci_hcd ohci_hcd ehci_hcd usbcore pcspkr snd_intel8x0m snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_intel8x0 snd_ac97_codec snd_mixer_oss ac97_bus snd_pcm snd_page_alloc snd_rtctimer snd_timer snd soundcore rtc psmouse nsc_ircc irda crc_ccitt cpufreq_ondemand evdev pcmcia yenta_socket rsrc_nonstatic pcmcia_core asus_laptop speedstep_centrino freq_table lm90 hwmon i2c_i801 [last unloaded: rfkill_backport]
Pid: 6116, comm: ksysguardd Not tainted 2.6.30.1-AP #3
Call Trace:
[<c03cae45>] ? __schedule+0x385/0x3a0
[<c03cb84c>] ? __mutex_lock_slowpath+0x6c/0xf0
[<c03cb769>] ? mutex_lock+0x9/0x10
[<f0a9b1d9>] ? cfg80211_wireless_stats+0x69/0x160 [cfg80211]
[<c03c2bff>] ? wireless_seq_show+0x3f/0x180
[<c0195c92>] ? seq_read+0x242/0x3d0
[<c0195a50>] ? seq_read+0x0/0x3d0
[<c01b7920>] ? proc_reg_read+0x0/0xb0
[<c01b7976>] ? proc_reg_read+0x56/0xb0
[<c017d805>] ? vfs_read+0xa5/0x150
[<c017b030>] ? do_sys_open+0xc0/0xf0
[<c017d971>] ? sys_read+0x41/0x70
[<c0102df4>] ? sysenter_do_call+0x12/0x26
This seems to have nothing in common with ath9k... It probably happens when a process uses the old wireless configuration API. It sometimes happens to iwconfig as well. Should I report this to the kernel bugzilla? All works fine with iw, so this may be related to some deprecated code.
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 23:42 ` Andrej Podzimek
@ 2009-07-17 23:46 ` Ashish Sharma
2009-07-18 0:08 ` Andrej Podzimek
0 siblings, 1 reply; 12+ messages in thread
From: Ashish Sharma @ 2009-07-17 23:46 UTC (permalink / raw)
To: ath9k-devel
Regarding the Iperf issue of 1Mbps performance with UDP, try with "-b
100Mbps" flag, as by default Iperf limits the sending rate to 1 MBps, so use
the bandwidth flag option to specify the sending rate.
- Ashish
On Fri, Jul 17, 2009 at 4:42 PM, Andrej Podzimek <andrej@podzimek.org>wrote:
> > ieee80211_regdom is the same thing as using 'iw reg set' but we will
> > eventually remove ieee80211_regdom module parameter. Please consider
> > abandoning it.
>
> I removed the option from modprobe.conf. The initialization looks very
> similar. This appears instead of the CZ regdomain:
>
> cfg80211: World regulatory domain updated:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
> However, two problems appeared:
>
> * spurious disconnections
> No probe response from AP 00:23:f8:22:aa:a6 after 200ms,
> disconnecting.
>
> * the card won't associate unless I set this manually:
> iw dev wlan0 set channel 6 HT40-
>
> > Using what? iperf? TCP or UDP?
>
> This is a *good* question! Yes, iperf. I didn't consider trying UDP before.
> The results are surprising, to say the least.
>
> TCP: 58 to 63 Mb/s
> UDP: 1 Mb/s
>
> This was measured during a transfer that took 30 seconds. I tried both IPv4
> and IPv6. (Presumably, results were almost the same.)
>
> The UDP problem does not seem to be caused by packet loss:
>
> [ ID] Interval Transfer Bandwidth Jitter
> Lost/Total Datagrams
> [ 3] 0.0-30.0 sec 3.74 MBytes 1.05 Mbits/sec 0.777 ms 5/
> 2675 (0.19%)
> [ 3] 0.0-30.0 sec 1 datagrams received out-of-order
>
> > I was under the impression 802.11n *requires QoS*, not sure why it
> > would let you disable it..
>
> Disabling QoS and enabling 40 MHz channels reduces the performance of
> 802.11g to about 10 Mb/s and the 802.11n adapter performs no better. When 40
> MHz channels are disabled, 802.11g devices work normally (24 Mb/s) without
> QoS, but 802.11n devices only work at g speeds.
>
> Simply put, disabling QoS probably disables 802.11n as well, although the
> web interface says it's enabled.
>
> > Are you using 2.4 GHz or 5 GHz? What channel/freq are you on? How many
> > APs can you detect nearby and what channels are they on? Try to set
> > your AP to a channel far away from the others.
>
> 2.4 GHz.
>
> There are mostly 3 visible APs on channels 1, 7 and 11. (Yes, that's quite
> a bad situation.) When I set automatic channel selection on the router, it
> sticks to channel 6. (I have never seen an automatic channel change.) All
> those visible APs are quite far away, below -75 dBm.
>
> I also tried channels 4 and 13 with the client set to HT+ and HT-
> respectively, but the speed was about 80% of what I would get with the
> default channel 6. (I didn't measure this in detail, just a standard 10s
> test.) (UDP was a disaster again.)
>
> > You should be able to do better than what you have. I'm not going to
> > defend 11n but you should realize IEEE-802.11n is being standardized,
> > Atheros turbo, or+ or whatever is not and will never get supported in
> > ath9k, and very likely also not in ath5k.
>
> This is *good* news.
> (G+ is not supported.) && (Bandwidth exceeds 54 Mb/s.) => (802.11n works
> somehow.)
>
> > You can check the ath9k rcstat:
> >
> > http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
> >
> > Please provide the output of that file after a few quick tests. Reset
> > the counters by reloading ath9k if you want to compare against some
> > different environment.
>
> Thanks for the info. I'll definitely try this tomorrow.
>
> > I have stuffed all pending patches into one file:
> >
> > http://bombadil.infradead.org/~mcgrof/patches/all.patch<http://bombadil.infradead.org/%7Emcgrof/patches/all.patch>
> >
> > if you want to test using wireless-testing directly. Not sure if this
> > will apply to compat-wireless cleanly.
>
> Yes, it will. Nothing rejected. I'm compiling that now and will report
> results.
>
> BTW, I ran into this weird error when watching the data rate and signal
> quality with ksysguard:
>
> BUG: scheduling while atomic: ksysguardd/6116/0x00000002
> Modules linked in: aes_i586 aes_generic ath9k mac80211 ath cfg80211
> rfkill_backport arc4 ecb ipv6 sco bnep l2cap bluetooth rng_core uinput
> ohci1394 ieee1394 tun usbhid dvb_usb_af9015 dvb_usb dvb_core ipw2200 libipw
> lib80211 8139too mii lp ppdev parport_pc parport uhci_hcd ohci_hcd ehci_hcd
> usbcore pcspkr snd_intel8x0m snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device snd_pcm_oss snd_intel8x0 snd_ac97_codec snd_mixer_oss
> ac97_bus snd_pcm snd_page_alloc snd_rtctimer snd_timer snd soundcore rtc
> psmouse nsc_ircc irda crc_ccitt cpufreq_ondemand evdev pcmcia yenta_socket
> rsrc_nonstatic pcmcia_core asus_laptop speedstep_centrino freq_table lm90
> hwmon i2c_i801 [last unloaded: rfkill_backport]
> Pid: 6116, comm: ksysguardd Not tainted 2.6.30.1-AP #3
> Call Trace:
> [<c03cae45>] ? __schedule+0x385/0x3a0
> [<c03cb84c>] ? __mutex_lock_slowpath+0x6c/0xf0
> [<c03cb769>] ? mutex_lock+0x9/0x10
> [<f0a9b1d9>] ? cfg80211_wireless_stats+0x69/0x160 [cfg80211]
> [<c03c2bff>] ? wireless_seq_show+0x3f/0x180
> [<c0195c92>] ? seq_read+0x242/0x3d0
> [<c0195a50>] ? seq_read+0x0/0x3d0
> [<c01b7920>] ? proc_reg_read+0x0/0xb0
> [<c01b7976>] ? proc_reg_read+0x56/0xb0
> [<c017d805>] ? vfs_read+0xa5/0x150
> [<c017b030>] ? do_sys_open+0xc0/0xf0
> [<c017d971>] ? sys_read+0x41/0x70
> [<c0102df4>] ? sysenter_do_call+0x12/0x26
>
> This seems to have nothing in common with ath9k... It probably happens when
> a process uses the old wireless configuration API. It sometimes happens to
> iwconfig as well. Should I report this to the kernel bugzilla? All works
> fine with iw, so this may be related to some deprecated code.
>
> Andrej
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090717/87ab727e/attachment.htm
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 23:46 ` Ashish Sharma
@ 2009-07-18 0:08 ` Andrej Podzimek
0 siblings, 0 replies; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-18 0:08 UTC (permalink / raw)
To: ath9k-devel
> Regarding the Iperf issue of 1Mbps performance with UDP, try with "-b
> 100Mbps" flag, as by default Iperf limits the sending rate to 1 MBps, so
> use the bandwidth flag option to specify the sending rate.
The option -b has no effect on my machine. I tried -b 100M, -b 500M, -b 100Mbps, -b 500Mbps and similar combinations, but it still shows the same result.
[andrej at argos ~]$ iperf -Vu -b 100M -c <*** IPv6 address ***>
WARNING: option -b is not valid for server mode
------------------------------------------------------------
Client connecting to <*** IPv6 address ***>, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 108 KByte (default)
------------------------------------------------------------
[ 3] local <*** IPv6 address ***> port 58878 connected with <*** IPv6 address ***> port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 892 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
This is weird. I also tried -b 100X, which did not produce any error message and the result was almost identical to the above. My version of iperf is 2.0.4.
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n badly slow
2009-07-17 21:24 ` Luis R. Rodriguez
2009-07-17 23:42 ` Andrej Podzimek
@ 2009-07-25 13:50 ` Andrej Podzimek
2009-07-25 14:16 ` [ath9k-devel] Zyxel NWD-170n warning Andrej Podzimek
2 siblings, 0 replies; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-25 13:50 UTC (permalink / raw)
To: ath9k-devel
> You can check the ath9k rcstat:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
>
> Please provide the output of that file after a few quick tests. Reset
> the counters by reloading ath9k if you want to compare against some
> different environment.
This is rcstat after two iperf TCP tests (one per direction), 30 seconds each:
Rate Success Retries XRetries PER
1.0: 0 0 0 0
2.0: 0 0 0 0
5.5: 0 0 0 0
11.0: 0 0 0 0
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 0 0 0 0
18.0: 0 0 0 0
24.0: 0 0 0 0
36.0: 0 0 0 0
48.0: 0 0 0 0
54.0: 0 0 0 0
6.5: 0 0 0 0
13.0: 0 0 0 0
19.5: 0 0 0 0
26.0: 0 0 0 0
39.0: 0 0 0 0
52.0: 0 0 0 0
58.5: 0 0 0 0
65.0: 0 0 0 0
13.0: 0 0 0 0
26.0: 0 0 0 0
39.0: 0 0 0 0
52.0: 0 0 0 0
78.0: 0 0 0 0
104.0: 0 0 0 0
117.0: 0 0 0 0
130.0: 0 0 0 0
13.5: 95 556 148 79
27.5: 20 34 12 15
40.5: 24 23 5 15
54.0: 24 41 10 15
81.5: 137 47 9 95
108.0: 0 0 0 0
121.5: 0 0 0 0
135.0: 0 0 0 0
150.0: 0 0 0 0
27.0: 0 0 0 0
54.0: 0 0 0 0
81.0: 0 0 0 0
108.0: 6488 698 22 35
162.0: 2985 1882 684 90
216.0: 637 1387 441 26
243.0: 81 36 8 90
270.0: 787 230 30 87
300.0: 33602 5242 49 30
Using 2.6.30.3 with today's compat-wireless.
The speeds shown by iperf:
67 Mb/s laptop->router
58 Mb/s router->laptop
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n warning
2009-07-17 21:24 ` Luis R. Rodriguez
2009-07-17 23:42 ` Andrej Podzimek
2009-07-25 13:50 ` Andrej Podzimek
@ 2009-07-25 14:16 ` Andrej Podzimek
2009-07-27 19:23 ` Luis R. Rodriguez
2 siblings, 1 reply; 12+ messages in thread
From: Andrej Podzimek @ 2009-07-25 14:16 UTC (permalink / raw)
To: ath9k-devel
Hello,
I got this warning when testing today's compat-wireless with iperf (to obtain some rcstat data).
------------[ cut here ]------------
WARNING: at /home/inst/compat-wireless-2009-07-24/net/mac80211/mlme.c:2500 ieee80211_mgd_deauth+0x90/0x100 [mac80211]()
Hardware name: M2N
Modules linked in: ath9k mac80211 ath cfg80211 rfkill_backport aes_i586 aes_generic rfkill ipv6 sco bnep l2cap bluetooth usbhid dvb_usb_af9015 dvb_usb dvb_core snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0m snd_intel8x0 ohci1394 snd_ac97_codec ac97_bus snd_pcm snd_timer ppdev uhci_hcd ieee1394 8139too mii parport_pc snd soundcore snd_page_alloc 8250_pci 8250 serial_core ehci_hcd usbcore rng_core pcspkr arc4 ecb uinput tun lp parport psmouse nsc_ircc irda crc_ccitt cpufreq_ondemand evdev pcmcia yenta_socket rsrc_nonstatic pcmcia_core asus_laptop speedstep_centrino freq_table lm90 hwmon i2c_i801 [last unloaded: cfg80211]
Pid: 29978, comm: wpa_supplicant Not tainted 2.6.30.3-AP #2
Call Trace:
[<c0122dae>] ? warn_slowpath_common+0x6e/0xb0
[<f1059c20>] ? ieee80211_mgd_deauth+0x90/0x100 [mac80211]
[<c0122e03>] ? warn_slowpath_null+0x13/0x20
[<f1059c20>] ? ieee80211_mgd_deauth+0x90/0x100 [mac80211]
[<f10103f1>] ? cfg80211_mlme_down+0xe1/0x1c0 [cfg80211]
[<f1002204>] ? cfg80211_netdev_notifier_call+0x104/0x310 [cfg80211]
[<c013afce>] ? notifier_call_chain+0x3e/0x70
[<c013b0a7>] ? raw_notifier_call_chain+0x17/0x20
[<c0361944>] ? dev_close+0x44/0xb0
[<c035ee7c>] ? __dev_set_rx_mode+0x2c/0xa0
[<c03615ad>] ? dev_change_flags+0x7d/0x1a0
[<c03a7958>] ? devinet_ioctl+0x678/0x740
[<c035f2fd>] ? __dev_get_by_name+0x6d/0x90
[<c0351d15>] ? sock_ioctl+0x65/0x260
[<c0351cb0>] ? sock_ioctl+0x0/0x260
[<c018a00b>] ? vfs_ioctl+0x1b/0xa0
[<c01667b1>] ? __do_fault+0x2f1/0x3e0
[<c018a0fe>] ? do_vfs_ioctl+0x6e/0x5b0
[<c0352cb3>] ? sys_send+0x33/0x40
[<c0353fc0>] ? sys_socketcall+0x1a0/0x270
[<c018a67d>] ? sys_ioctl+0x3d/0x70
[<c0102df4>] ? sysenter_do_call+0x12/0x26
---[ end trace 924bfb300766e361 ]---
Andrej
^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Zyxel NWD-170n warning
2009-07-25 14:16 ` [ath9k-devel] Zyxel NWD-170n warning Andrej Podzimek
@ 2009-07-27 19:23 ` Luis R. Rodriguez
0 siblings, 0 replies; 12+ messages in thread
From: Luis R. Rodriguez @ 2009-07-27 19:23 UTC (permalink / raw)
To: ath9k-devel
On Sat, Jul 25, 2009 at 07:16:29AM -0700, Andrej Podzimek wrote:
> Hello,
>
> I got this warning when testing today's compat-wireless with iperf (to obtain some rcstat data).
>
> ------------[ cut here ]------------
> WARNING: at /home/inst/compat-wireless-2009-07-24/net/mac80211/mlme.c:2500 ieee80211_mgd_deauth+0x90/0x100 [mac80211]()
It was a real warning, already fixed I imagine via:
commit 77206c0d83a2e3d6df1dc1c6548ef866408687d4
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Sat Jul 25 11:58:36 2009 +0200
mac80211: fix receiving deauth
Marcel reported a warning, which quite obviously comes
from an oversight in the code handling deauth frames,
and which resulted in multiple follow-up warnings due
to this missing handling. This patch adds the missing
deauth handling (telling cfg80211 about it) and also
removes the follow-up warnings since they could happen
due to races even if nothing is wrong. I've explained
the races in the comments.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
You should report these in the future on linux-wireless directly, they are real.
Luis
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-07-27 19:23 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-17 16:03 [ath9k-devel] Zyxel NWD-170n badly slow Andrej Podzimek
2009-07-17 16:30 ` Luis R. Rodriguez
2009-07-17 17:31 ` Andrej Podzimek
2009-07-17 17:59 ` Luis R. Rodriguez
2009-07-17 20:54 ` Andrej Podzimek
2009-07-17 21:24 ` Luis R. Rodriguez
2009-07-17 23:42 ` Andrej Podzimek
2009-07-17 23:46 ` Ashish Sharma
2009-07-18 0:08 ` Andrej Podzimek
2009-07-25 13:50 ` Andrej Podzimek
2009-07-25 14:16 ` [ath9k-devel] Zyxel NWD-170n warning Andrej Podzimek
2009-07-27 19:23 ` Luis R. Rodriguez
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.