[rt2x00-users] [RFC/RFT 0/8] rt2x00: Various clean-ups and RT3572 fixes.

[Andreas Hartmann]

Hi Gertjan,

Gertjan van Wingerde schrieb:
> This patch series contains some general clean-ups and a series of fixes
> to the RT3572 channel switching code inside rt2800pci and rt2800usb.
> These fixes are based on the v2.5.0.0 version of the RT3572 Ralink driver
> and bring rt2x00 closer to that driver with respect to channel switching.
> 
> With these changes the performance seems to be enhanced as I can measure
> over 100 Mbps as raw network speed. However, there still seem to be some
> stalls, but AFAICT these resolve automatically.
> 
> Please review and test.
> I plan to submit upstream mid to end of this week, so please comment before
> that time.

I tried to test but I'm confused about all these patches the last few
days / weeks :-) - unfortunately, they didn't apply altogether.

I tested on the base of compat-wireless 3.2-1 with the following
additional patches (mainly):

patchset 1
1-3 rt2800pci: remove rt2800pci_set_state function
2-3 rt2800: Add documentation on MCU requests
3-3 rt2800pci: Fix 'Error - MCU request failed' during initialization
1-5 rt2800usb: initialize H2M_INT_SRC register.patch
2-5 rt2800: reset RF using MCU command after firmware load
3-5 rt2800: disable DMA after firmware load
4-5 rt2800: zero MAC_SYS_CTRL bits during BBP and MAC reset
5-5 rt2800usb: remove PWR_PIN_CFG=0x3 during init


patchset 2
rt2800: radio 3xxx: add channel switch calibration routines
rt2800: radio 3xxx: program RF_R1 during channel switch
rt2800: radio 3xxx: reprogram only lower bits of RF_R3
rt2800: radio 3xxxx: channel switch RX_TX calibration fixes


patchset 3

rt2x00: Introduce concept of driver data in struct rt2x00_dev
rt2x00: Use struct rt2x00_dev driver data in rt2800{pci, usb}
rt2x00: Update comment on freq_offset field in struct rt2x00_dev
rt2x00: Use saved BBP 25 and 26 values when configuring channel on RT3572
rt2x00: Fix RFCSR 12 & 13 programming on RT3572 channel switching
rt2x00: Align RT3572 channel switch RFCSR 1 programming with Ralink driver
rt2x00: Fix RT3572 channel switch RFCSR 7 programming
rt2x00: Correctly set txmixer_gain in RT3572 channel switching


mac80211: revert: retry sending failed BAR frames later instead of
tearing down aggr


I wasn't able to apply patchset 2 and 3 at the same time.


For testing, I used netperf (TCP_MAERTS, TCP_STREAM, TCP_SENDFILE). The
wlan had the following parameters:
WPA2-EAPTLS, CCMP, nl80211.n, 2.4 GHz, 40MHz. I'll try to do some tests
later on using 5 GHz.


AP (rt6860)
===========
mac80211 revert patch
patchset 1 + 3



rt3572usb (tested on a 32 bit single core CPU, Linksys WUSB600Nv2)
=========
patchset 1 + 3

with kernel 3.1 -> unusable because of phy0-> rt2x00usb_vendor_request:
Error - Vendor Request 0x101c failed for offset 0x0580 with error -71


with kernel 2.6.37.6
- I never saw it working like this with rt2x00usb
- extremely high ping latency (about 3 ms vs. < 1ms legacy)
- Throughput is fine under excellent radio conditions (STA -> AP even
much better than legacy), but is getting really worse if the conditions
worsen. I can see then a growing unsteadiness, which can't be seen as
much with the legacy driver. The throughput of the legacy driver is at
this situation between 40% to 80% higher.
- The load on the system is 1 during running netperf (mostly system
load - CONFIG_RT2X00_DEBUG was switched off). For comparison: with the
legacy driver, the load is between 0 and
0.1.
- I didn't get any stall during my tests.
- The already well known millions of warning entries to messages as long
as CONFIG_RT2X00_DEBUG is switched on, are remaining.


-open: Should this patch "mac80211: revert: retry sending failed BAR
frames later instead of tearing down aggr" applied, too? For AP, it's
irrecoverable. It should be really urgently fixed!



Kind regards,
Andreas