Hi,
I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
an AP. The problem is that since version
compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
properly. In this driver version and all later you've broken
something!
The point is if wmm_enabled=1 then max transfer speed slows down to
100-200 KBytes\s. Without wmm_enabled speed is ok and about 4-5
MBytes\s (my max connection rate is 65mbps).
But some wireless clients won't connect in 802.11n mode when this
option is disabled, this is why I need it.
My hostapd.conf:
interface=wlan0
driver=nl80211
ssid=Server
hw_mode=g
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wmm_enabled=1
ieee80211n=1
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=***
rsn_pairwise=CCMP
(Ubuntu Server 10.04, driver module is rt2800usb.)
I've tested the speed in both directions and it seems that speed from
client to AP is fine, while from AP to client is very slow.
I've build on different kernels and also tried two other dongles?with
no difference.?Currently I have the latest stable compat-wireless
driver and the problem is the same. And same thing for current
bleeding edge.
The last release where it wasn't broken yet is
compat-wireless-2010-12-13.tar.bz2 or stable
compat-wireless-2.6.37-4.tar.bz2. But I can't use them at all because
they have stability issues.
Ok, but maybe we could try to fix this somehow?
I could provide some additional info if it helps.
I've tried two quite common dongles: D-link DWA 125 (rt2870) and
TP-LINK WN-7200ND (rt3070). Tried different kernels, and the only
thing which made difference is the driver version.
So I beleive this couldn't be an isuue only specific to my configuration.
2011/7/20 Helmut Schaa <[email protected]>:
> Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> 2011/7/20 Helmut Schaa <[email protected]>:
>> > Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> >> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
>> >> an AP. The problem is that since version
>> >> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
>> >> properly. In this driver version and all later you've broken
>> >> something!
>> >
>> > So, 2010-12-14 already shows the problem you've described while 2010-12-13
>> > does not, right?
>> Yes, correct.
>
> One major change from 12-13 to 12-14 was the queue refactoring. Haven't found
> anything else that looks related. However, this patchset is quite big and
> really changed the way the queues are handled in rt2x00. So it's not trivial
> to find the root cause for your problem ...
>
> Helmut
>
Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
> This patch won't apply on current compat-wireless-2011-07-20.tar.bz2
>
> (Stripping trailing CRs from patch.)
> patching file b/drivers/net/wireless/rt2x00/rt2800lib.c
> Hunk #1 FAILED at 4194.
> 1 out of 1 hunk FAILED -- saving rejects to file
> b/drivers/net/wireless/rt2x00/rt2800lib.c.rej
> (Stripping trailing CRs from patch.)
> patching file b/drivers/net/wireless/rt2x00/rt2800usb.c
> Hunk #1 FAILED at 527.
> patch unexpectedly ends in middle of line
> Hunk #2 FAILED at 820.
> 2 out of 2 hunks FAILED -- saving rejects to file
> b/drivers/net/wireless/rt2x00/rt2800usb.c.rej
>
> Should I use another version of compat wireless or edit files manually?
Just edit manually, it's not much ...
> Also I have no stability issues, the connection is stable, but as I
> said the TX speed from AP running rt2x00 (the driver is in Master
> mode) to client is extremely slow in 802.11n+WMM mode.
Yeah, understood. That's what I saw in STA mode as well. Now I get a stable
transmit speed >20Mbps (MCS7 20Mhz).
> And this is only WMM mode related, because wIthout it everything is fine.
Disabling WMM might force some clients to disable 11n, not sure though how
this relates.
Helmut
I've just tried to apply these patches to the 2011-03-13 as you said
and none of the applied.
2011/7/20 Juan Carlos Garza Fernandez <[email protected]>:
> Hi all,
>
> On Wed, Jul 20, 2011 at 5:09 PM, Helmut Schaa
> <[email protected]> wrote:
>> Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>>> 2011/7/20 Helmut Schaa <[email protected]>:
>>> > Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>>> >> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
>>> >> an AP. The problem is that since version
>>> >> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
>>> >> properly. In this driver version and all later you've broken
>>> >> something!
>>> >
>>> > So, 2010-12-14 already shows the problem you've described while 2010-12-13
>>> > does not, right?
>>> Yes, correct.
>>
>> One major change from 12-13 to 12-14 was the queue refactoring. Haven't found
>> anything else that looks related. However, this patchset is quite big and
>> really changed the way the queues are handled in rt2x00. So it's not trivial
>> to find the root cause for your problem ...
>
> I am running an AP with hostapd 0.73 with also a 1T1R dongle and it
> works (maybe not as fast as it could, but I am happy with its
> performance).
> I use the compat-wireless version from 2011-03-13 plus some patches
> that Helmut suggested (which are already merged in the main branch):
>
> [1] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=878a2bbc20100d8bccf84cc058373fe7de2e6501
> [2] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=4f3ab1e88d8b5ce4852d075016ca784a00383452
> [3] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=c8cb3a0af064fb5d9cbbaa16bd2f308ba3b90ceb
> [4] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=66b096e6ad64f718425d2de9a70d82ba187d7db4
>
> I later tried the version compat-wireless-2011-05-05 and it did not
> work, some major changes took
> place in between, and I unfortunately did not have time to go deeper,
> so I stayed with my
> running system.
>
> Since then, some other things have been changed in the TX queues and I
> will eventually try it again.
>
>>
>> Helmut
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> ________________________________
> Juan Carlos Garza
>
Hi all,
On Wed, Jul 20, 2011 at 5:09 PM, Helmut Schaa
<[email protected]> wrote:
> Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> 2011/7/20 Helmut Schaa <[email protected]>:
>> > Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> >> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
>> >> an AP. The problem is that since version
>> >> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
>> >> properly. In this driver version and all later you've broken
>> >> something!
>> >
>> > So, 2010-12-14 already shows the problem you've described while 2010-12-13
>> > does not, right?
>> Yes, correct.
>
> One major change from 12-13 to 12-14 was the queue refactoring. Haven't found
> anything else that looks related. However, this patchset is quite big and
> really changed the way the queues are handled in rt2x00. So it's not trivial
> to find the root cause for your problem ...
I am running an AP with hostapd 0.73 with also a 1T1R dongle and it
works (maybe not as fast as it could, but I am happy with its
performance).
I use the compat-wireless version from 2011-03-13 plus some patches
that Helmut suggested (which are already merged in the main branch):
[1] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=878a2bbc20100d8bccf84cc058373fe7de2e6501
[2] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=4f3ab1e88d8b5ce4852d075016ca784a00383452
[3] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=c8cb3a0af064fb5d9cbbaa16bd2f308ba3b90ceb
[4] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=66b096e6ad64f718425d2de9a70d82ba187d7db4
I later tried the version compat-wireless-2011-05-05 and it did not
work, some major changes took
place in between, and I unfortunately did not have time to go deeper,
so I stayed with my
running system.
Since then, some other things have been changed in the TX queues and I
will eventually try it again.
>
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
________________________________
Juan Carlos Garza
On Thu, Jul 21, 2011 at 1:53 PM, Stanislav Demakov <[email protected]> wrote:
> So eventually, are you going to fix or discover this bug yourself?
Please try this on top of a current compat-wireless. It improved STA
mode stability in
rt2800usb for me quite a bit. But this is not a valid fix, it's just
for tracking down the
problem a bit further.
Thanks,
Helmut
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 1ac1f39..3d9d152 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4194,8 +4194,7 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
/*
* Disable powersaving as default on PCI devices.
*/
- if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev))
- rt2x00dev->hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
+ rt2x00dev->hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
/*
* Initialize all hw fields.
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index f9c58cd..602677c 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -527,7 +527,7 @@ static void rt2800usb_txdone(struct rt2x00_dev *rt2x00dev)
entry = NULL;
while (!rt2x00queue_empty(queue)) {
entry = rt2x00queue_get_entry(queue, Q_INDEX_DONE);
- if (rt2800usb_txdone_entry_check(entry, reg))
+ /*if (rt2800usb_txdone_entry_check(entry, reg))*/
break;
}
@@ -820,7 +820,7 @@ static const struct data_queue_desc rt2800usb_queue_rx = {
};
static const struct data_queue_desc rt2800usb_queue_tx = {
- .entry_num = 64,
+ .entry_num = 8,
.data_size = AGGREGATION_SIZE,
.desc_size = TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
.priv_size = sizeof(struct queue_entry_priv_usb),
This patch won't apply on current compat-wireless-2011-07-20.tar.bz2
(Stripping trailing CRs from patch.)
patching file b/drivers/net/wireless/rt2x00/rt2800lib.c
Hunk #1 FAILED at 4194.
1 out of 1 hunk FAILED -- saving rejects to file
b/drivers/net/wireless/rt2x00/rt2800lib.c.rej
(Stripping trailing CRs from patch.)
patching file b/drivers/net/wireless/rt2x00/rt2800usb.c
Hunk #1 FAILED at 527.
patch unexpectedly ends in middle of line
Hunk #2 FAILED at 820.
2 out of 2 hunks FAILED -- saving rejects to file
b/drivers/net/wireless/rt2x00/rt2800usb.c.rej
Should I use another version of compat wireless or edit files manually?
Also I have no stability issues, the connection is stable, but as I
said the TX speed from AP running rt2x00 (the driver is in Master
mode) to client is extremely slow in 802.11n+WMM mode.
And this is only WMM mode related, because wIthout it everything is fine.
2011/7/21 Helmut Schaa <[email protected]>:
> On Thu, Jul 21, 2011 at 1:53 PM, Stanislav Demakov <[email protected]> wrote:
>> So eventually, are you going to fix or discover this bug yourself?
>
> Please try this on top of a current compat-wireless. It improved STA
> mode stability in
> rt2800usb for me quite a bit. But this is not a valid fix, it's just
> for tracking down the
> problem a bit further.
>
> Thanks,
> Helmut
>
> ---
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 1ac1f39..3d9d152 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -4194,8 +4194,7 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> ? ? ? ?/*
> ? ? ? ? * Disable powersaving as default on PCI devices.
> ? ? ? ? */
> - ? ? ? if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev))
> - ? ? ? ? ? ? ? rt2x00dev->hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
> + ? ? ? rt2x00dev->hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
>
> ? ? ? ?/*
> ? ? ? ? * Initialize all hw fields.
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
> b/drivers/net/wireless/rt2x00/rt2800usb.c
> index f9c58cd..602677c 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -527,7 +527,7 @@ static void rt2800usb_txdone(struct rt2x00_dev *rt2x00dev)
> ? ? ? ? ? ? ? ?entry = NULL;
> ? ? ? ? ? ? ? ?while (!rt2x00queue_empty(queue)) {
> ? ? ? ? ? ? ? ? ? ? ? ?entry = rt2x00queue_get_entry(queue, Q_INDEX_DONE);
> - ? ? ? ? ? ? ? ? ? ? ? if (rt2800usb_txdone_entry_check(entry, reg))
> + ? ? ? ? ? ? ? ? ? ? ? /*if (rt2800usb_txdone_entry_check(entry, reg))*/
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
>
> @@ -820,7 +820,7 @@ static const struct data_queue_desc rt2800usb_queue_rx = {
> ?};
>
> ?static const struct data_queue_desc rt2800usb_queue_tx = {
> - ? ? ? .entry_num ? ? ? ? ? ? ?= 64,
> + ? ? ? .entry_num ? ? ? ? ? ? ?= 8,
> ? ? ? ?.data_size ? ? ? ? ? ? ?= AGGREGATION_SIZE,
> ? ? ? ?.desc_size ? ? ? ? ? ? ?= TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
> ? ? ? ?.priv_size ? ? ? ? ? ? ?= sizeof(struct queue_entry_priv_usb),
>
Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
> Quick note: changed .entry_num value back to 64 and the speed raised
> even more! Now it's about 2.5 MB/s.
64 is not a safe value in this case and rt2800usb_txdone_entry_check tries
to protect against a special case where the tx status for single frames
gets "lost". But at least we now know a little more about this issue.
> But still there is still room for improvement. :)
> Looks like rt2800usb_txdone_entry_check was the major cause for the delay.
Ok, thanks for trying. I'll think about a proper solution without causing
regressions ...
Helmut
Hello Helmut,
I applied your patch to compat-wireless-2011-07-18 on an Intel Core i5
CPU M460 2.53 GHz (quad core) with kernel
kernel-desktop-3.0.rc7-1.1.x86_64 from OpenSuSE and tested with Linksys
WUSB600N v2 (it's a rt3572 chip) on 40MHz / 802.11n . I just run it a
few days ago with the same compat-wireless package and it was totally
unusable.
With your patch, it's surprisingly running now - ok, the performance is
not as good as with rt3572sta and it isn't stable under high load (you
know - netperf and so ...). It just stalls after a few minutes. There
are at this moment no entries in messages. But before, I get an entry:
Jul 21 16:59:42 pc2 kernel: [20443.730419] phy0 ->
rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out,
invoke forced tx handler
The ping-latency is great - about 0.5 ms (rt3572sta: about 0.7 ms). The
performance with netperf is:
rt3572sta rt2800usb
supplicant -> hostapd 6.3 M/s 4 M/s
hostapd -> supplicant 7.7 M/s 5.7 M/s
If you could increase the stability under load and if you could increase
the performance a bit more, it would be great!
Some device information from messages:
Jul 21 16:58:20 pc2 kernel: [20361.966847] usb 2-1.1: new high speed USB
device number 8 using ehci_hcd
Jul 21 16:58:20 pc2 kernel: [20362.084522] usb 2-1.1: New USB device
found, idVendor=1737, idProduct=0079
Jul 21 16:58:20 pc2 kernel: [20362.084529] usb 2-1.1: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Jul 21 16:58:20 pc2 kernel: [20362.084534] usb 2-1.1: Product: Linksys
WUSB600N Wireless-N USB Network Adapter with Dual-Band ver. 2
Jul 21 16:58:20 pc2 kernel: [20362.084538] usb 2-1.1: Manufacturer: Linksys
Jul 21 16:58:20 pc2 mtp-probe: checking bus 2, device 8:
"/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1"
Jul 21 16:58:20 pc2 mtp-probe: bus: 2, device: 8 was not an MTP device
Jul 21 16:58:20 pc2 kernel: [20362.161618] cfg80211: Calling CRDA to
update world regulatory domain
Jul 21 16:58:20 pc2 kernel: [20362.169831] cfg80211: World regulatory
domain updated:
Jul 21 16:58:20 pc2 kernel: [20362.169839] cfg80211: (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 21 16:58:20 pc2 kernel: [20362.169841] cfg80211: (2402000 KHz -
2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.169843] cfg80211: (2457000 KHz -
2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.169845] cfg80211: (2474000 KHz -
2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.169847] cfg80211: (5170000 KHz -
5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.169848] cfg80211: (5735000 KHz -
5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.169873] cfg80211: Calling CRDA for
country: DE
Jul 21 16:58:20 pc2 kernel: [20362.176622] cfg80211: Regulatory domain
changed to country: DE
Jul 21 16:58:20 pc2 kernel: [20362.176626] cfg80211: (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 21 16:58:20 pc2 kernel: [20362.176629] cfg80211: (2400000 KHz -
2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.176631] cfg80211: (5150000 KHz -
5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.176633] cfg80211: (5470000 KHz -
5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
Jul 21 16:58:20 pc2 kernel: [20362.259525] usb 2-1.1: reset high speed
USB device number 8 using ehci_hcd
Jul 21 16:58:20 pc2 kernel: [20362.372816] phy0 -> rt2x00_set_chip: Info
- Chipset detected - rt: 3572, rf: 0009, rev: 0221.
Jul 21 16:58:20 pc2 kernel: [20362.373070] ieee80211 phy0: Selected rate
control algorithm 'minstrel_ht'
Jul 21 16:58:20 pc2 kernel: [20362.374341] Registered led device:
rt2800usb-phy0::radio
Jul 21 16:58:20 pc2 kernel: [20362.374430] Registered led device:
rt2800usb-phy0::assoc
Jul 21 16:58:20 pc2 kernel: [20362.374470] Registered led device:
rt2800usb-phy0::quality
Jul 21 16:58:20 pc2 kernel: [20362.374850] usbcore: registered new
interface driver rt2800usb
Jul 21 16:58:20 pc2 kernel: [20362.395110] udev[7976]: renamed network
interface wlan0 to wlan1
Jul 21 16:58:35 pc2 kernel: [20376.646437] phy0 ->
rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'.
Jul 21 16:58:35 pc2 kernel: [20376.649110] phy0 ->
rt2x00lib_request_firmware: Info - Firmware detected - version: 0.236.
Jul 21 16:58:35 pc2 kernel: [20376.868997] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
Jul 21 16:58:35 pc2 kernel: [20376.870375] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
Jul 21 16:58:35 pc2 kernel: [20376.871619] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
Jul 21 16:58:35 pc2 kernel: [20376.872867] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.
Jul 21 16:58:35 pc2 kernel: [20376.874723] ADDRCONF(NETDEV_UP): wlan1:
link is not ready
Jul 21 16:58:38 pc2 kernel: [20380.335178] wlan1: authenticate with
68:7f:74:fb:39:ee (try 1)
Jul 21 16:58:38 pc2 kernel: [20380.336708] wlan1: authenticated
Jul 21 16:58:38 pc2 kernel: [20380.351817] wlan1: associate with
68:7f:74:fb:39:ee (try 1)
Jul 21 16:58:38 pc2 kernel: [20380.354946] wlan1: RX AssocResp from
68:7f:74:fb:39:ee (capab=0x411 status=0 aid=1)
Jul 21 16:58:38 pc2 kernel: [20380.354953] wlan1: associated
Jul 21 16:58:38 pc2 kernel: [20380.355048] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 2 - CWmin: 4, CWmax: 10, Aifs: 3, TXop: 0.
Jul 21 16:58:38 pc2 kernel: [20380.356823] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 3 - CWmin: 4, CWmax: 10, Aifs: 7, TXop: 0.
Jul 21 16:58:38 pc2 kernel: [20380.358414] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 93.
Jul 21 16:58:38 pc2 kernel: [20380.359820] phy0 -> rt2x00mac_conf_tx:
Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 2, TXop: 46.
Jul 21 16:58:38 pc2 kernel: [20380.385902] ADDRCONF(NETDEV_CHANGE):
wlan1: link becomes ready
Jul 21 16:58:38 pc2 kernel: [20380.385970] cfg80211: Calling CRDA for
country: DE
Jul 21 16:58:38 pc2 kernel: [20380.390979] cfg80211: Regulatory domain
changed to country: DE
Jul 21 16:58:38 pc2 kernel: [20380.390983] cfg80211: (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 21 16:58:38 pc2 kernel: [20380.390988] cfg80211: (2400000 KHz -
2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 21 16:58:38 pc2 kernel: [20380.390993] cfg80211: (5150000 KHz -
5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 21 16:58:38 pc2 kernel: [20380.390996] cfg80211: (5470000 KHz -
5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
wlan1 IEEE 802.11abgn ESSID:"Hurra"
Mode:Managed Frequency:2.412 GHz Access Point: 11:22:33:44:55:66
Bit Rate=130 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=47/70 Signal level=-63 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:79 Missed beacon:0
Kind regards,
Andreas
PS
before this patch, I got millions of entries in messages like this,
absolutely no performance (about 1 k/s or nothing):
Jul 20 17:51:18 pc2 kernel: [ 5496.416075] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 63
Jul 20 17:51:18 pc2 kernel: [ 5496.416098] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 0
Jul 20 17:51:18 pc2 kernel: [ 5496.416112] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 1
Jul 20 17:51:18 pc2 kernel: [ 5496.416128] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 3
Jul 20 17:51:18 pc2 kernel: [ 5496.416142] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 4
Jul 20 17:51:18 pc2 kernel: [ 5496.416157] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 6
Jul 20 17:51:18 pc2 kernel: [ 5496.416170] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 7
Jul 20 17:51:18 pc2 kernel: [ 5496.416186] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 9
Jul 20 17:51:18 pc2 kernel: [ 5496.416200] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 10
Jul 20 17:51:18 pc2 kernel: [ 5496.417799] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 12
Jul 20 17:51:18 pc2 kernel: [ 5496.417814] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 14
Jul 20 17:51:18 pc2 kernel: [ 5496.417823] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 15
Jul 20 17:51:18 pc2 kernel: [ 5496.420927] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 16
Jul 20 17:51:18 pc2 kernel: [ 5496.420948] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 17
Jul 20 17:51:18 pc2 kernel: [ 5496.421164] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 19
Jul 20 17:51:18 pc2 kernel: [ 5496.421169] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 20
Jul 20 17:51:18 pc2 kernel: [ 5496.421802] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 22
Jul 20 17:51:18 pc2 kernel: [ 5496.421829] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 23
Jul 20 17:51:18 pc2 kernel: [ 5496.421922] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 25
Jul 20 17:51:18 pc2 kernel: [ 5496.424431] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 26
Jul 20 17:51:18 pc2 kernel: [ 5496.424459] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 27
Jul 20 17:51:18 pc2 kernel: [ 5496.424683] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 29
Jul 20 17:51:18 pc2 kernel: [ 5496.424708] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 30
Jul 20 17:51:18 pc2 kernel: [ 5496.424916] phy0 ->
rt2800usb_txdone_entry_check: Warning - TX status report missed for
queue 2 entry 32
Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
> an AP. The problem is that since version
> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
> properly. In this driver version and all later you've broken
> something!
So, 2010-12-14 already shows the problem you've described while 2010-12-13
does not, right?
Helmut
Just applied your patch to 2011-07-20 manually and now download speed
is around 1 MByte/s which is better than it was before (100-200kb/s).
Maybe you could give an advice what else should I try to change?
Because in 2010-12-13 version DL speed is still better and around
4MByte\s.
2011/7/21 Stanislav Demakov <[email protected]>:
>>>Disabling WMM might force some clients to disable 11n, not sure though how
> this relates.
>
> That's right, this is why I need it to work properly when it's enabled.
> E.g my netbook can handle 11n without WMM and I get 65mbps, but
> iDevices (ipad ipod) will only connect in G mode in this case.
>
>
> 2011/7/21 Helmut Schaa <[email protected]>:
>> Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
>>> This patch won't apply on current compat-wireless-2011-07-20.tar.bz2
>>>
>>> (Stripping trailing CRs from patch.)
>>> patching file b/drivers/net/wireless/rt2x00/rt2800lib.c
>>> Hunk #1 FAILED at 4194.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> b/drivers/net/wireless/rt2x00/rt2800lib.c.rej
>>> (Stripping trailing CRs from patch.)
>>> patching file b/drivers/net/wireless/rt2x00/rt2800usb.c
>>> Hunk #1 FAILED at 527.
>>> patch unexpectedly ends in middle of line
>>> Hunk #2 FAILED at 820.
>>> 2 out of 2 hunks FAILED -- saving rejects to file
>>> b/drivers/net/wireless/rt2x00/rt2800usb.c.rej
>>>
>>> Should I use another version of compat wireless or edit files manually?
>>
>> Just edit manually, it's not much ...
>>
>>> Also I have no stability issues, the connection is stable, but as I
>>> said the TX speed from AP running rt2x00 (the driver is in Master
>>> mode) to client is extremely slow in 802.11n+WMM mode.
>>
>> Yeah, understood. That's what I saw in STA mode as well. Now I get a stable
>> transmit speed >20Mbps (MCS7 20Mhz).
>>
>>> And this is only WMM mode related, because wIthout it everything is fine.
>>
>> Disabling WMM might force some clients to disable 11n, not sure though how
>> this relates.
>>
>> Helmut
>>
>
Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
> 2011/7/20 Helmut Schaa <[email protected]>:
> > Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
> >> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
> >> an AP. The problem is that since version
> >> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
> >> properly. In this driver version and all later you've broken
> >> something!
> >
> > So, 2010-12-14 already shows the problem you've described while 2010-12-13
> > does not, right?
> Yes, correct.
One major change from 12-13 to 12-14 was the queue refactoring. Haven't found
anything else that looks related. However, this patchset is quite big and
really changed the way the queues are handled in rt2x00. So it's not trivial
to find the root cause for your problem ...
Helmut
Quick note: changed .entry_num value back to 64 and the speed raised
even more! Now it's about 2.5 MB/s.
But still there is still room for improvement. :)
Looks like rt2800usb_txdone_entry_check was the major cause for the delay.
2011/7/21 Stanislav Demakov <[email protected]>:
> Just applied your patch to 2011-07-20 manually and now download speed
> is around 1 MByte/s which is better than it was before (100-200kb/s).
>
> Maybe you could give an advice what else should I try to change?
> Because in 2010-12-13 version DL speed is still better and around
> 4MByte\s.
>
> 2011/7/21 Stanislav Demakov <[email protected]>:
>>>>Disabling WMM might force some clients to disable 11n, not sure though how
>> this relates.
>>
>> That's right, this is why I need it to work properly when it's enabled.
>> E.g my netbook can handle 11n without WMM and I get 65mbps, but
>> iDevices (ipad ipod) will only connect in G mode in this case.
>>
>>
>> 2011/7/21 Helmut Schaa <[email protected]>:
>>> Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
>>>> This patch won't apply on current compat-wireless-2011-07-20.tar.bz2
>>>>
>>>> (Stripping trailing CRs from patch.)
>>>> patching file b/drivers/net/wireless/rt2x00/rt2800lib.c
>>>> Hunk #1 FAILED at 4194.
>>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>>> b/drivers/net/wireless/rt2x00/rt2800lib.c.rej
>>>> (Stripping trailing CRs from patch.)
>>>> patching file b/drivers/net/wireless/rt2x00/rt2800usb.c
>>>> Hunk #1 FAILED at 527.
>>>> patch unexpectedly ends in middle of line
>>>> Hunk #2 FAILED at 820.
>>>> 2 out of 2 hunks FAILED -- saving rejects to file
>>>> b/drivers/net/wireless/rt2x00/rt2800usb.c.rej
>>>>
>>>> Should I use another version of compat wireless or edit files manually?
>>>
>>> Just edit manually, it's not much ...
>>>
>>>> Also I have no stability issues, the connection is stable, but as I
>>>> said the TX speed from AP running rt2x00 (the driver is in Master
>>>> mode) to client is extremely slow in 802.11n+WMM mode.
>>>
>>> Yeah, understood. That's what I saw in STA mode as well. Now I get a stable
>>> transmit speed >20Mbps (MCS7 20Mhz).
>>>
>>>> And this is only WMM mode related, because wIthout it everything is fine.
>>>
>>> Disabling WMM might force some clients to disable 11n, not sure though how
>>> this relates.
>>>
>>> Helmut
>>>
>>
>
Thank you for the assistance, ask If you'll need anyhitng else to test.
By the way I've tested transfer speed in both directions and the results are:
from Server to Client: ~2.5 MB/s (after applying your patch and
changing value 8 back to 64)
from Client to Server: ~5.3 MB/s
Both machines uses 1T1R modules and connection is 65mbps (20mhz, MCS7)
So I guess in ideal case Server to Client speed should be at least
twice faster than it is now.
Interesting that in G mode(54mbps) the same transmit speed is around 3.2 MB/s.
2011/7/22 Helmut Schaa <[email protected]>:
> Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
>> Quick note: changed .entry_num value back to 64 and the speed raised
>> even more! Now it's about 2.5 MB/s.
>
> 64 is not a safe value in this case and rt2800usb_txdone_entry_check tries
> to protect against a special case where the tx status for single frames
> gets "lost". But at least we now know a little more about this issue.
>
>> But still there is still room for improvement. :)
>> Looks like rt2800usb_txdone_entry_check was the major cause for the delay.
>
> Ok, thanks for trying. I'll think about a proper solution without causing
> regressions ...
>
> Helmut
>
>>Disabling WMM might force some clients to disable 11n, not sure though how
this relates.
That's right, this is why I need it to work properly when it's enabled.
E.g my netbook can handle 11n without WMM and I get 65mbps, but
iDevices (ipad ipod) will only connect in G mode in this case.
2011/7/21 Helmut Schaa <[email protected]>:
> Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
>> This patch won't apply on current compat-wireless-2011-07-20.tar.bz2
>>
>> (Stripping trailing CRs from patch.)
>> patching file b/drivers/net/wireless/rt2x00/rt2800lib.c
>> Hunk #1 FAILED at 4194.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> b/drivers/net/wireless/rt2x00/rt2800lib.c.rej
>> (Stripping trailing CRs from patch.)
>> patching file b/drivers/net/wireless/rt2x00/rt2800usb.c
>> Hunk #1 FAILED at 527.
>> patch unexpectedly ends in middle of line
>> Hunk #2 FAILED at 820.
>> 2 out of 2 hunks FAILED -- saving rejects to file
>> b/drivers/net/wireless/rt2x00/rt2800usb.c.rej
>>
>> Should I use another version of compat wireless or edit files manually?
>
> Just edit manually, it's not much ...
>
>> Also I have no stability issues, the connection is stable, but as I
>> said the TX speed from AP running rt2x00 (the driver is in Master
>> mode) to client is extremely slow in 802.11n+WMM mode.
>
> Yeah, understood. That's what I saw in STA mode as well. Now I get a stable
> transmit speed >20Mbps (MCS7 20Mhz).
>
>> And this is only WMM mode related, because wIthout it everything is fine.
>
> Disabling WMM might force some clients to disable 11n, not sure though how
> this relates.
>
> Helmut
>
Hi,
So eventually, are you going to fix or discover this bug yourself?
2011/7/20 Helmut Schaa <[email protected]>:
> Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> 2011/7/20 Helmut Schaa <[email protected]>:
>> > Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> >> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
>> >> an AP. The problem is that since version
>> >> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
>> >> properly. In this driver version and all later you've broken
>> >> something!
>> >
>> > So, 2010-12-14 already shows the problem you've described while 2010-12-13
>> > does not, right?
>> Yes, correct.
>
> One major change from 12-13 to 12-14 was the queue refactoring. Haven't found
> anything else that looks related. However, this patchset is quite big and
> really changed the way the queues are handled in rt2x00. So it's not trivial
> to find the root cause for your problem ...
>
> Helmut
>
Yes, correct.
This is how I've discovered it:
At first, I've accidentally found that stable version 2.6.37-4.tar.bz2
does not have this problem, because every later stable version does.
Then I've decided to try other drivers that have similar release
date\archive size.
So eventually I was in the folder
http://www.orbit-lab.org/kernel/compat-wireless-2.6/2010/12/ and tried
the first and the last one. And compat-wireless-2010-12-01.tar.bz2 was
fine, while compat-wireless-2010-12-26.tar.bz2 wasn't.
Then I've tried the middle one, etc. In the end I was certain that
something has changed between 13th and 14th. So since 2010-12-14 the
problem is present.
2011/7/20 Helmut Schaa <[email protected]>:
> Am Mittwoch, 20. Juli 2011 schrieb Stanislav Demakov:
>> I'm using hostapd 0.73 and 1T1R rt2x00 based wireless dongle to create
>> an AP. The problem is that since version
>> compat-wireless-2010-12-14.tar.bz2 802.11n mode is not working
>> properly. In this driver version and all later you've broken
>> something!
>
> So, 2010-12-14 already shows the problem you've described while 2010-12-13
> does not, right?
>
> Helmut
>
Hi,
Any update on fixing poor tx speed in rt2x00 driver?
2011/7/22 Stanislav Demakov <[email protected]>:
> Thank you for the assistance, ask If you'll need anyhitng else to test.
>
> By the way I've tested transfer speed in both directions and the results are:
>
> from Server to Client: ~2.5 MB/s (after applying your patch and
> changing value 8 back to 64)
> from Client to Server: ~5.3 MB/s
>
> Both machines uses 1T1R modules and connection is 65mbps (20mhz, MCS7)
> So I guess in ideal case Server to Client speed should be at least
> twice faster than it is now.
> Interesting that in G mode(54mbps) the same transmit speed is around 3.2 MB/s.
>
> 2011/7/22 Helmut Schaa <[email protected]>:
>> Am Donnerstag, 21. Juli 2011 schrieb Stanislav Demakov:
>>> Quick note: changed .entry_num value back to 64 and the speed raised
>>> even more! Now it's about 2.5 MB/s.
>>
>> 64 is not a safe value in this case and rt2800usb_txdone_entry_check tries
>> to protect against a special case where the tx status for single frames
>> gets "lost". But at least we now know a little more about this issue.
>>
>>> But still there is still room for improvement. :)
>>> Looks like rt2800usb_txdone_entry_check was the major cause for the delay.
>>
>> Ok, thanks for trying. I'll think about a proper solution without causing
>> regressions ...
>>
>> Helmut
>>
>