| Message ID | CAGXE3d9HgRvdJModc3hSA25+jLktZJ3i997oq7GfZz4dUJfuvw@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 <helmut.schaa@googlemail.com>: > On Thu, Jul 21, 2011 at 1:53 PM, Stanislav Demakov <s.demakov@gmail.com> 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), > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>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 <helmut.schaa@googlemail.com>: > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <s.demakov@gmail.com>: >>>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 <helmut.schaa@googlemail.com>: >> 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 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <s.demakov@gmail.com>: > 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 <s.demakov@gmail.com>: >>>>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 <helmut.schaa@googlemail.com>: >>> 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 >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <helmut.schaa@googlemail.com>: > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Any update on fixing poor tx speed in rt2x00 driver? 2011/7/22 Stanislav Demakov <s.demakov@gmail.com>: > 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 <helmut.schaa@googlemail.com>: >> 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 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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),
On Thu, Jul 21, 2011 at 1:53 PM, Stanislav Demakov <s.demakov@gmail.com> 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 --- -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html