2.6.38: rt2800usb: high latency (1000ms)?

2.6.38: rt2800usb: high latency (1000ms)?

[Justin Piszcz]

Hello,

I recall using this driver in staging and it crashing my machine, now 
thats its no longer in staging, I thought I'd give it another try..  Using 
the following wireless usb adapter, I'm seeing very high latency when using
the device in Linux, (with Windows, there are no problems).  Using Debian 
Testing + wpa_supplicant, using the following USB adapter:

Bus 001 Device 004: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 
Wireless Adapter

$ ping wireless-host
PING wireless-host (192.168.1.2) 56(84) bytes of data.
64 bytes from wireless-host (192.168.1.2): icmp_req=1 ttl=64 time=1002 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=2 ttl=64 time=3.84 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=3 ttl=64 time=23.3 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=4 ttl=64 time=40.1 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=5 ttl=64 time=991 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=6 ttl=64 time=0.583 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=7 ttl=64 time=1033 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=8 ttl=64 time=33.2 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=9 ttl=64 time=991 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=10 ttl=64 time=2.66 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=11 ttl=64 time=1029 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=12 ttl=64 time=31.3 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=14 ttl=64 time=997 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=15 ttl=64 time=0.884 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=16 ttl=64 time=1049 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=17 ttl=64 time=49.6 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=18 ttl=64 time=989 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=19 ttl=64 time=1.62 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=20 ttl=64 time=1047 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=21 ttl=64 time=47.6 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=22 ttl=64 time=982 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=23 ttl=64 time=0.607 ms

--- wireless-host ping statistics ---
24 packets transmitted, 22 received, 8% packet loss, time 23009ms
rtt min/avg/max/mdev = 0.583/470.533/1049.181/494.399 ms, pipe 2

I am using the following ralink firmware:
ii  firmware-ralink                     0.29                        Binary firmware for Ralink wireless cards

$ dpkg -L firmware-ralink
/.
/lib
/lib/firmware
/lib/firmware/rt3090.bin
/lib/firmware/rt2860.bin
/lib/firmware/rt73.bin
/lib/firmware/rt3071.bin
/lib/firmware/rt2561.bin
/lib/firmware/rt3070.bin
/lib/firmware/rt2661.bin
/lib/firmware/rt2870.bin
/lib/firmware/rt2561s.bin
/usr
/usr/share
/usr/share/bug
/usr/share/bug/firmware-ralink
/usr/share/bug/firmware-ralink/presubj
/usr/share/doc
/usr/share/doc/firmware-ralink
/usr/share/doc/firmware-ralink/changelog.gz
/usr/share/doc/firmware-ralink/copyright

Is there a certain firmware or other driver I should be using for this
USB wireless device so I do not get spouts of 1 second latency?

Justin.

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Ivo Van Doorn]

Hi,

> I recall using this driver in staging and it crashing my machine, now thats
> its no longer in staging, I thought I'd give it another try..  Using the

The rt2800usb was not in staging but has been inside the main kernel
tree for quite
some time already, the alternative rt2870sta was in staging and will
be removed very soon.

> following wireless usb adapter, I'm seeing very high latency when using
> the device in Linux, (with Windows, there are no problems).  Using Debian
> Testing + wpa_supplicant, using the following USB adapter:

Can you try disabling powersaving?
iwconfig wlan0 power off

Ivo

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1476 bytes --]



On Wed, 13 Apr 2011, Ivo Van Doorn wrote:

> Hi,
>
>> I recall using this driver in staging and it crashing my machine, now thats
>> its no longer in staging, I thought I'd give it another try..  Using the
>
> The rt2800usb was not in staging but has been inside the main kernel
> tree for quite
> some time already, the alternative rt2870sta was in staging and will
> be removed very soon.
>
>> following wireless usb adapter, I'm seeing very high latency when using
>> the device in Linux, (with Windows, there are no problems).  Using Debian
>> Testing + wpa_supplicant, using the following USB adapter:
>
> Can you try disabling powersaving?
> iwconfig wlan0 power off
>
> Ivo
>

Hi,

Wow! That was it, now its interactive again.

64 bytes from wireless-host (192.168.1.2): icmp_req=1 ttl=64 time=0.581 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=2 ttl=64 time=0.647 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=3 ttl=64 time=0.569 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=4 ttl=64 time=0.686 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=5 ttl=64 time=0.674 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=6 ttl=64 time=1.18 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=7 ttl=64 time=1.77 ms
64 bytes from wireless-host (192.168.1.2): icmp_req=8 ttl=64 time=0.654 ms

Thanks, so its recommend to keep this off then, can that be set as the 
driver default?

Justin.

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Daniel Halperin]

Ugh! Couldn't you configure the stupid mailing list filter to only
drop rich text mails that have [PATCH or [RFC or [RFT in the subject,
e.g.? Original mail below.

(sorry for the resend, Justin and Ivo).

Dan

On Wed, Apr 13, 2011 at 9:23 AM, Daniel Halperin
<dhalperi@cs.washington.edu> wrote:
>
> On Wed, Apr 13, 2011 at 9:01 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>>
>>> Can you try disabling powersaving?
>>> iwconfig wlan0 power off
>>>
>> Wow! That was it, now its interactive again.
>>
>> 64 bytes from wireless-host (192.168.1.2): icmp_req=1 ttl=64 time=0.581 ms
>> 64 bytes from wireless-host (192.168.1.2): icmp_req=2 ttl=64 time=0.647 ms
>>
>> Thanks, so its recommend to keep this off then, can that be set as the driver default?
>>
>
> That's a bad idea, what you're seeing is likely completely a red herring. Wi-Fi power saving mode saves energy by putting the RF hardware most of the time. This is a Good Thing.
> Power save is designed to kick in only when the load is very slow; the client's network stack should automatically disable power save during times of high load, e.g., during a download or a VoIP call. You should run some tests to see if this is actually occurring; there may be a bug in the rtl implementation.
> The real problem here is that your ping test has invalid assumptions. One packet/second is not enough load to disable Wi-Fi power save, so you should not see interactive ping times. Again, this is a good thing and something I doubt you want to disable! (Assuming that RTL's implementation isn't fundamentally broken elsewhere) It certainly should NOT be the driver default.
> Try again with sudo ping -i 0.01 -s 1400 (e.g., to ping with large packets every 10 ms); this should probably trigger the logic that automatically disables the power saving mode. Or try pinging while doing a 1 Mbit UDP transfer (e.g., with iperf).
> Dan

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3683 bytes --]



On Wed, 13 Apr 2011, Daniel Halperin wrote:

> Ugh! Couldn't you configure the stupid mailing list filter to only
> drop rich text mails that have [PATCH or [RFC or [RFT in the subject,
> e.g.? Original mail below.
>
> (sorry for the resend, Justin and Ivo).
>
> Dan
>
> On Wed, Apr 13, 2011 at 9:23 AM, Daniel Halperin
> <dhalperi@cs.washington.edu> wrote:
>>
>> On Wed, Apr 13, 2011 at 9:01 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>>>
>>>> Can you try disabling powersaving?
>>>> iwconfig wlan0 power off
>>>>
>>> Wow! That was it, now its interactive again.
>>>
>>> 64 bytes from wireless-host (192.168.1.2): icmp_req=1 ttl=64 time=0.581 ms
>>> 64 bytes from wireless-host (192.168.1.2): icmp_req=2 ttl=64 time=0.647 ms
>>>
>>> Thanks, so its recommend to keep this off then, can that be set as the driver default?
>>>
>>
>> That's a bad idea, what you're seeing is likely completely a red herring. Wi-Fi power saving mode saves energy by putting the RF hardware most of the time. This is a Good Thing.
>> Power save is designed to kick in only when the load is very slow; the client's network stack should automatically disable power save during times of high load, e.g., during a download or a VoIP call. You should run some tests to see if this is actually occurring; there may be a bug in the rtl implementation.
>> The real problem here is that your ping test has invalid assumptions. One packet/second is not enough load to disable Wi-Fi power save, so you should not see interactive ping times. Again, this is a good thing and something I doubt you want to disable! (Assuming that RTL's implementation isn't fundamentally broken elsewhere) It certainly should NOT be the driver default.
>> Try again with sudo ping -i 0.01 -s 1400 (e.g., to ping with large packets every 10 ms); this should probably trigger the logic that automatically disables the power saving mode. Or try pinging while doing a 1 Mbit UDP transfer (e.g., with iperf).
>> Dan
>

Hi,

When powersave is enabled, it is very jumpy, I've used satellite comms before
and (~600ms-1200ms was more smooth) as it did not jump around as much.  The
application is just a standalone desktop with minimal activity for the majority
of the time, maybe thats why..

With powersave disabled, I now see 0% packet loss (802.11n) and low ping
times, this looks like the proper solution for the wireless USB device I
am using.  By the way, is it possible/are there wireless USB devices out there
that support wake on wireless lan (WOWL?

Your ping command with power off:
1408 bytes from server (192.168.1.2): icmp_req=539 ttl=64 time=1.07 ms
1408 bytes from server (192.168.1.2): icmp_req=540 ttl=64 time=1.31 ms
1408 bytes from server (192.168.1.2): icmp_req=541 ttl=64 time=1.07 ms
1408 bytes from server (192.168.1.2): icmp_req=542 ttl=64 time=1.26 ms

Your ping command with power on:
1408 bytes from server (192.168.1.2): icmp_req=649 ttl=64 time=1.80 ms
1408 bytes from server (192.168.1.2): icmp_req=650 ttl=64 time=1.85 ms
1408 bytes from server (192.168.1.2): icmp_req=651 ttl=64 time=2.86 ms
1408 bytes from server (192.168.1.2): icmp_req=652 ttl=64 time=1.46 ms

You are correct, if there is a lot of traffic, its good, but if the system
is relatively idle and all that's going on is an SSH session, there is horrible
latency.

So the fix/workaround, for Debian-based distributions (if you come across 
this problem):

File: /etc/network/interfaces

-- snip --

# Wireless
auto wlan0
iface wlan0 inet dhcp
   wpa-ssid your-ssid
   wpa-psk your-private-key
   post-up /sbin/iwconfig wlan0 power off

-- snip --

Justin.

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Daniel Halperin]

On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> Hi,
>
> When powersave is enabled, it is very jumpy, I've used satellite comms
> before
> and (~600ms-1200ms was more smooth) as it did not jump around as much.  The
> application is just a standalone desktop with minimal activity for the
> majority
> of the time, maybe thats why..
>
> With powersave disabled, I now see 0% packet loss (802.11n) and low ping
> times, this looks like the proper solution for the wireless USB device I
> am using.  By the way, is it possible/are there wireless USB devices out
> there
> that support wake on wireless lan (WOWL?
>
> Your ping command with power off:
> 1408 bytes from server (192.168.1.2): icmp_req=539 ttl=64 time=1.07 ms
> 1408 bytes from server (192.168.1.2): icmp_req=540 ttl=64 time=1.31 ms
> 1408 bytes from server (192.168.1.2): icmp_req=541 ttl=64 time=1.07 ms
> 1408 bytes from server (192.168.1.2): icmp_req=542 ttl=64 time=1.26 ms
>
> Your ping command with power on:
> 1408 bytes from server (192.168.1.2): icmp_req=649 ttl=64 time=1.80 ms
> 1408 bytes from server (192.168.1.2): icmp_req=650 ttl=64 time=1.85 ms
> 1408 bytes from server (192.168.1.2): icmp_req=651 ttl=64 time=2.86 ms
> 1408 bytes from server (192.168.1.2): icmp_req=652 ttl=64 time=1.46 ms
>
> You are correct, if there is a lot of traffic, its good, but if the system
> is relatively idle and all that's going on is an SSH session, there is
> horrible
> latency.

Gotcha. I might still look around in the network stack and/or driver
and see what the time constants are. For instance:

(1) What is the AP's beacon period and DTIM? Typical values are 100
TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
wakeup) which should imply a mean of 100 and max of 200 ms delay even
on pings.

(2) How long does the client wait after waking up to go back to sleep?
It should be at least a few seconds. For ssh, then, you should see
something like a 100-200 ms delay for the first key and then nothing
at all unless you stop typing for a bit.

I'm SSHing over a Wi-Fi link that uses power save right this second,
and have for years. It's not generally an issue, I suspect something
worse is going on.

Dan

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3316 bytes --]



On Wed, 13 Apr 2011, Daniel Halperin wrote:

> On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>> Hi,
>>
>> When powersave is enabled, it is very jumpy, I've used satellite comms
>> before
>> and (~600ms-1200ms was more smooth) as it did not jump around as much.  The
>> application is just a standalone desktop with minimal activity for the
>> majority
>> of the time, maybe thats why..
>>
>> With powersave disabled, I now see 0% packet loss (802.11n) and low ping
>> times, this looks like the proper solution for the wireless USB device I
>> am using.  By the way, is it possible/are there wireless USB devices out
>> there
>> that support wake on wireless lan (WOWL?
>>
>> Your ping command with power off:
>> 1408 bytes from server (192.168.1.2): icmp_req=539 ttl=64 time=1.07 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=540 ttl=64 time=1.31 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=541 ttl=64 time=1.07 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=542 ttl=64 time=1.26 ms
>>
>> Your ping command with power on:
>> 1408 bytes from server (192.168.1.2): icmp_req=649 ttl=64 time=1.80 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=650 ttl=64 time=1.85 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=651 ttl=64 time=2.86 ms
>> 1408 bytes from server (192.168.1.2): icmp_req=652 ttl=64 time=1.46 ms
>>
>> You are correct, if there is a lot of traffic, its good, but if the system
>> is relatively idle and all that's going on is an SSH session, there is
>> horrible
>> latency.
>
> Gotcha. I might still look around in the network stack and/or driver
> and see what the time constants are. For instance:
>
> (1) What is the AP's beacon period and DTIM? Typical values are 100
> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
> wakeup) which should imply a mean of 100 and max of 200 ms delay even
> on pings.
I am using a WNDR3700 with default settings in terms of beacons/etc.  No
issues with any device (laptop, computer, etc (in windows)), I have two
wireless USB adapters (bought two) and in Windows, no problems, I don't think
it is the WNDR3700.  As far as linux/wpa-supplicant, using default settings.


>
> (2) How long does the client wait after waking up to go back to sleep?
> It should be at least a few seconds. For ssh, then, you should see
> something like a 100-200 ms delay for the first key and then nothing
> at all unless you stop typing for a bit.
It lags with each word I type, it is terrible.  If I run something like
dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
comes back.


>
> I'm SSHing over a Wi-Fi link that uses power save right this second,
> and have for years. It's not generally an issue, I suspect something
> worse is going on.
Maybe the wireless usb adapters do not function well in Linux with power save
on.

I bought them awhile ago, they had the highest reviews, and in Windows,
they did do 10-15MiB/s, in Linux, I see ~4.6MiB/s (but that was with power 
save on) about the same, 4.5MiB/s.
http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE

100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 23.2803 s, 4.5 MB/s

Justin.

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Daniel Halperin]

On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>> (1) What is the AP's beacon period and DTIM? Typical values are 100
>> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
>> wakeup) which should imply a mean of 100 and max of 200 ms delay even
>> on pings.
>
> I am using a WNDR3700 with default settings in terms of beacons/etc.  No
> issues with any device (laptop, computer, etc (in windows)), I have two
> wireless USB adapters (bought two) and in Windows, no problems, I don't
> think
> it is the WNDR3700.  As far as linux/wpa-supplicant, using default settings.

Not enough info. What does "iw dev wlan1 scan dump"  (it might not be
wlan1 for you) say for "beacon interval"?

Does anyone know how to get the DTIM period out of iw?

>> (2) How long does the client wait after waking up to go back to sleep?
>> It should be at least a few seconds. For ssh, then, you should see
>> something like a 100-200 ms delay for the first key and then nothing
>> at all unless you stop typing for a bit.
>
> It lags with each word I type, it is terrible.  If I run something like
> dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
> comes back.

Sorry; I meant what is the software stack configured to do? Do some
looking around.

>> I'm SSHing over a Wi-Fi link that uses power save right this second,
>> and have for years. It's not generally an issue, I suspect something
>> worse is going on.
>
> Maybe the wireless usb adapters do not function well in Linux with power
> save
> on.
>
> I bought them awhile ago, they had the highest reviews, and in Windows,
> they did do 10-15MiB/s, in Linux, I see ~4.6MiB/s (but that was with power
> save on) about the same, 4.5MiB/s.
> http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE

Yeah, these might indicate a fairly sizable problem in the Linux drivers IMO.

Dan

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4072 bytes --]



On Wed, 13 Apr 2011, Daniel Halperin wrote:

> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>> (1) What is the AP's beacon period and DTIM? Typical values are 100
>>> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
>>> wakeup) which should imply a mean of 100 and max of 200 ms delay even
>>> on pings.
>>
>> I am using a WNDR3700 with default settings in terms of beacons/etc.  No
>> issues with any device (laptop, computer, etc (in windows)), I have two
>> wireless USB adapters (bought two) and in Windows, no problems, I don't
>> think
>> it is the WNDR3700.  As far as linux/wpa-supplicant, using default settings.
>
> Not enough info. What does "iw dev wlan1 scan dump"  (it might not be
> wlan1 for you) say for "beacon interval"?

# iw dev wlan0 scan dump

BSS (hidden) (on wlan0) -- associated
         TSF: 103430650682 usec (1d, 04:43:50)
         freq: 2417
         beacon interval: 100
         capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
         signal: -59.00 dBm
         last seen: 1345742 ms ago
         SSID: (hidden)
         Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
         DS Parameter set: channel 2
         RSN:     * Version: 1
                  * Group cipher: TKIP
                  * Pairwise ciphers: CCMP TKIP
                  * Authentication suites: PSK
                  * Capabilities: (0x0000)
         WPA:     * Version: 1
                  * Group cipher: TKIP
                  * Pairwise ciphers: CCMP TKIP
                  * Authentication suites: PSK
         ERP: <no flags>
         Extended supported rates: 24.0 36.0 48.0 54.0
         WMM:     * Parameter version 1
                  * u-APSD
                  * BE: CW 15-1023, AIFSN 3
                  * BK: CW 15-1023, AIFSN 7
                  * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
                  * VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
         HT capabilities:
                 Capabilities: 0x11ce
                         HT20/HT40
                         SM Power Save disabled
                         RX HT40 SGI
                         TX STBC
                         RX STBC 1-stream
                         Max AMSDU length: 7935 bytes
                         DSSS/CCK HT40
                 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                 Minimum RX AMPDU time spacing: 1/2 usec (0x02)
                 HT RX MCS rate indexes supported: 0-15
                 HT TX MCS rate indexes are undefined
         WPS:     * Version: 1.0
                  * Manufacturer: Netgear, Inc.
                  * Model: WNDR3700
                  * Device name: (hidden)
                  * Config methods: Ethernet, Label, PBC
>
> Does anyone know how to get the DTIM period out of iw?
>
>>> (2) How long does the client wait after waking up to go back to sleep?
>>> It should be at least a few seconds. For ssh, then, you should see
>>> something like a 100-200 ms delay for the first key and then nothing
>>> at all unless you stop typing for a bit.
>>
>> It lags with each word I type, it is terrible.  If I run something like
>> dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
>> comes back.
>
> Sorry; I meant what is the software stack configured to do? Do some
> looking around.
>
>>> I'm SSHing over a Wi-Fi link that uses power save right this second,
>>> and have for years. It's not generally an issue, I suspect something
>>> worse is going on.
>>
>> Maybe the wireless usb adapters do not function well in Linux with power
>> save
>> on.
>>
>> I bought them awhile ago, they had the highest reviews, and in Windows,
>> they did do 10-15MiB/s, in Linux, I see ~4.6MiB/s (but that was with power
>> save on) about the same, 4.5MiB/s.
>> http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE
>
> Yeah, these might indicate a fairly sizable problem in the Linux drivers IMO.
>
> Dan
>

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Joshua Scoggins]

I have an ASUS N-13 USB wireless adapter (which uses the 3070 chipset)
and have never ever had an issue with it. The only thing that I had
issues with was that certain functions would act
erratically until I upgraded to 2.6.37. I'm not sure if I'm using the
staging driver or not (I can't
get to the machine right now) but I believe that the module was called
rt2800 or something like that. It connects to a DSL/wireless router
combo made by netgear that is pretty bad but works
for my parents needs. It has massive latency issues connecting to web
sites but never an issue with SSH.

I also have a WNDR3700 but that machine does not connect to that
network. I notice that you're using WPA1 instead of WPA2. In my
experience I have found that WPA1 can cause issues on certain wireless
chipsets especially atheros and broadcom so it could be WPA1 is
causing the latency issue. It could also be that you are not
connecting to the router at 802.11n speeds but 802.11g. If you look at
your log it shows supported speeds as being a max of 54.0 Megabits per
second. This translates to about 5.4 megabytes per second ideally. The
reason why windows gets better speeds is because it is actually
connected at 802.11n speeds. It seems that you have a configuration
issue going on. Try connecting the wireless adapter to the 5.0 ghz
network instead of the 2.4 gigahertz network and see if you get a
speed improvement. On the 5.0 ghz band only 802.11a/n are supported so
there is no possibility of connecting at g speeds. If your adapter
doesn't support the 5.0 ghz band then it seems the driver is limiting
the adapter to g speeds.

Josh

On Wed, Apr 13, 2011 at 1:36 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
>
> On Wed, 13 Apr 2011, Daniel Halperin wrote:
>
>> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <jpiszcz@lucidpixels.com>
>> wrote:
>>>>
>>>> (1) What is the AP's beacon period and DTIM? Typical values are 100
>>>> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
>>>> wakeup) which should imply a mean of 100 and max of 200 ms delay even
>>>> on pings.
>>>
>>> I am using a WNDR3700 with default settings in terms of beacons/etc.  No
>>> issues with any device (laptop, computer, etc (in windows)), I have two
>>> wireless USB adapters (bought two) and in Windows, no problems, I don't
>>> think
>>> it is the WNDR3700.  As far as linux/wpa-supplicant, using default
>>> settings.
>>
>> Not enough info. What does "iw dev wlan1 scan dump"  (it might not be
>> wlan1 for you) say for "beacon interval"?
>
> # iw dev wlan0 scan dump
>
> BSS (hidden) (on wlan0) -- associated
>        TSF: 103430650682 usec (1d, 04:43:50)
>        freq: 2417
>        beacon interval: 100
>        capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
>        signal: -59.00 dBm
>        last seen: 1345742 ms ago
>        SSID: (hidden)
>        Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
>        DS Parameter set: channel 2
>        RSN:     * Version: 1
>                 * Group cipher: TKIP
>                 * Pairwise ciphers: CCMP TKIP
>                 * Authentication suites: PSK
>                 * Capabilities: (0x0000)
>        WPA:     * Version: 1
>                 * Group cipher: TKIP
>                 * Pairwise ciphers: CCMP TKIP
>                 * Authentication suites: PSK
>        ERP: <no flags>
>        Extended supported rates: 24.0 36.0 48.0 54.0
>        WMM:     * Parameter version 1
>                 * u-APSD
>                 * BE: CW 15-1023, AIFSN 3
>                 * BK: CW 15-1023, AIFSN 7
>                 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
>                 * VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
>        HT capabilities:
>                Capabilities: 0x11ce
>                        HT20/HT40
>                        SM Power Save disabled
>                        RX HT40 SGI
>                        TX STBC
>                        RX STBC 1-stream
>                        Max AMSDU length: 7935 bytes
>                        DSSS/CCK HT40
>                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>                Minimum RX AMPDU time spacing: 1/2 usec (0x02)
>                HT RX MCS rate indexes supported: 0-15
>                HT TX MCS rate indexes are undefined
>        WPS:     * Version: 1.0
>                 * Manufacturer: Netgear, Inc.
>                 * Model: WNDR3700
>                 * Device name: (hidden)
>                 * Config methods: Ethernet, Label, PBC
>>
>> Does anyone know how to get the DTIM period out of iw?
>>
>>>> (2) How long does the client wait after waking up to go back to sleep?
>>>> It should be at least a few seconds. For ssh, then, you should see
>>>> something like a 100-200 ms delay for the first key and then nothing
>>>> at all unless you stop typing for a bit.
>>>
>>> It lags with each word I type, it is terrible.  If I run something like
>>> dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
>>> comes back.
>>
>> Sorry; I meant what is the software stack configured to do? Do some
>> looking around.
>>
>>>> I'm SSHing over a Wi-Fi link that uses power save right this second,
>>>> and have for years. It's not generally an issue, I suspect something
>>>> worse is going on.
>>>
>>> Maybe the wireless usb adapters do not function well in Linux with power
>>> save
>>> on.
>>>
>>> I bought them awhile ago, they had the highest reviews, and in Windows,
>>> they did do 10-15MiB/s, in Linux, I see ~4.6MiB/s (but that was with
>>> power
>>> save on) about the same, 4.5MiB/s.
>>>
>>> http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE
>>
>> Yeah, these might indicate a fairly sizable problem in the Linux drivers
>> IMO.
>>
>> Dan
>

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Igor Plyatov]

Dear Daniel,
> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz<jpiszcz@lucidpixels.com>  wrote:
>>> (1) What is the AP's beacon period and DTIM? Typical values are 100
>>> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
>>> wakeup) which should imply a mean of 100 and max of 200 ms delay even
>>> on pings.
>> I am using a WNDR3700 with default settings in terms of beacons/etc.  No
>> issues with any device (laptop, computer, etc (in windows)), I have two
>> wireless USB adapters (bought two) and in Windows, no problems, I don't
>> think
>> it is the WNDR3700.  As far as linux/wpa-supplicant, using default settings.
> Not enough info. What does "iw dev wlan1 scan dump"  (it might not be
> wlan1 for you) say for "beacon interval"?
>
> Does anyone know how to get the DTIM period out of iw?
>
# iw dev wlan0 scan dump
BSS 74:ea:3a:e4:fa:6e (on wlan0) -- associated
     TSF: 499843461 usec (0d, 00:08:19)
     freq: 2442
     beacon interval: 100
     capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
     signal: -51.00 dBm
     last seen: 510 ms ago
     Information elements from Probe Response frame:
     SSID: mynet2
     Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
     DS Parameter set: channel 7
     RSN:     * Version: 1
          * Group cipher: CCMP
          * Pairwise ciphers: CCMP
          * Authentication suites: PSK
          * Capabilities: (0x0000)
     ERP: <no flags>
     Extended supported rates: 24.0 36.0 48.0 54.0
     WMM:     * Parameter version 1
          * u-APSD
          * BE: CW 15-1023, AIFSN 3
          * BK: CW 15-1023, AIFSN 7
          * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
          * VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
     HT capabilities:
         Capabilities: 0x104e
             HT20/HT40
             SM Power Save disabled
             RX HT40 SGI
             No RX STBC
             Max AMSDU length: 3839 bytes
             DSSS/CCK HT40
         Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
         Minimum RX AMPDU time spacing: 8 usec (0x06)
         HT RX MCS rate indexes supported: 0-15
         HT TX MCS rate indexes are undefined
     WPS:     * Version: 1.0
          * Wi-Fi Protected Setup State: 2 (Configured)
          * Response Type: 3 (AP)
          * Unknown TLV (0x1047, 16 bytes): 00 00 00 00 00 00 10 00 00 
00 74 ea 3a e4 fa 6e
          * Manufacturer: TP-LINK
          * Model: TL-WR1043N
          * Model Number: 1.0
          * Serial Number: 1.0
          * Primary Device Type: 6-0050f204-1
          * Device name: Wireless Router TL-WR1043N
          * Config methods: Ethernet, Label, PBC
          * RF Bands: 0x1

>>> (2) How long does the client wait after waking up to go back to sleep?
>>> It should be at least a few seconds. For ssh, then, you should see
>>> something like a 100-200 ms delay for the first key and then nothing
>>> at all unless you stop typing for a bit.
>> It lags with each word I type, it is terrible.  If I run something like
>> dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
>> comes back.
> Sorry; I meant what is the software stack configured to do? Do some
> looking around.
What do you mean here?

Best regards!
--
Igor Plyatov

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Igor Plyatov]

Hi!

> On Wed, 13 Apr 2011, Daniel Halperin wrote:
>
>> On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz 
>> <jpiszcz@lucidpixels.com> wrote:
>>> Hi,
>>>
>>> When powersave is enabled, it is very jumpy, I've used satellite comms
>>> before
>>> and (~600ms-1200ms was more smooth) as it did not jump around as 
>>> much.  The
>>> application is just a standalone desktop with minimal activity for the
>>> majority
>>> of the time, maybe thats why..
>>>
>>> With powersave disabled, I now see 0% packet loss (802.11n) and low 
>>> ping
>>> times, this looks like the proper solution for the wireless USB 
>>> device I
>>> am using.  By the way, is it possible/are there wireless USB devices 
>>> out
>>> there
>>> that support wake on wireless lan (WOWL?
>>>
>>> Your ping command with power off:
>>> 1408 bytes from server (192.168.1.2): icmp_req=539 ttl=64 time=1.07 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=540 ttl=64 time=1.31 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=541 ttl=64 time=1.07 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=542 ttl=64 time=1.26 ms
>>>
>>> Your ping command with power on:
>>> 1408 bytes from server (192.168.1.2): icmp_req=649 ttl=64 time=1.80 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=650 ttl=64 time=1.85 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=651 ttl=64 time=2.86 ms
>>> 1408 bytes from server (192.168.1.2): icmp_req=652 ttl=64 time=1.46 ms
>>>
>>> You are correct, if there is a lot of traffic, its good, but if the 
>>> system
>>> is relatively idle and all that's going on is an SSH session, there is
>>> horrible
>>> latency.
>>
>> Gotcha. I might still look around in the network stack and/or driver
>> and see what the time constants are. For instance:
>>
>> (1) What is the AP's beacon period and DTIM? Typical values are 100
>> TUs for beacons (102.4 ms) and 2 for DTIM (2 beacons per power-save
>> wakeup) which should imply a mean of 100 and max of 200 ms delay even
>> on pings.
> I am using a WNDR3700 with default settings in terms of beacons/etc.  No
> issues with any device (laptop, computer, etc (in windows)), I have two
> wireless USB adapters (bought two) and in Windows, no problems, I 
> don't think
> it is the WNDR3700.  As far as linux/wpa-supplicant, using default 
> settings.
>
>
>>
>> (2) How long does the client wait after waking up to go back to sleep?
>> It should be at least a few seconds. For ssh, then, you should see
>> something like a 100-200 ms delay for the first key and then nothing
>> at all unless you stop typing for a bit.
> It lags with each word I type, it is terrible.  If I run something like
> dmesg or ps auxww, the entire session freezes for 5-10 seconds before it
> comes back.

Yes, it's terrible. I have the same problems with ping and ssh with 
latest GIT
linux on my ARM platform and two different USB Wi-Fi adapters based on
RT3070 chipset ("D-Link DWA-125" and "Qcom LR802UKN3").

>
>>
>> I'm SSHing over a Wi-Fi link that uses power save right this second,
>> and have for years. It's not generally an issue, I suspect something
>> worse is going on.
> Maybe the wireless usb adapters do not function well in Linux with 
> power save
> on.
>
> I bought them awhile ago, they had the highest reviews, and in Windows,
> they did do 10-15MiB/s, in Linux, I see ~4.6MiB/s (but that was with 
> power save on) about the same, 4.5MiB/s.
> http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE 
>
>
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB) copied, 23.2803 s, 4.5 MB/s
>
> Justin.

Best regards!
--
Igor Plyatov

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Walter Goldens]

> > I recall using this driver in staging and it crashing
> my machine, now thats
> > its no longer in staging, I thought I'd give it
> another try..  Using the
> 
> The rt2800usb was not in staging but has been inside the
> main kernel
> tree for quite
> some time already, the alternative rt2870sta was in staging
> and will
> be removed very soon.
> 
> > following wireless usb adapter, I'm seeing very high
> latency when using
> > the device in Linux, (with Windows, there are no
> problems).  Using Debian
> > Testing + wpa_supplicant, using the following USB
> adapter:
> 
> Can you try disabling powersaving?
> iwconfig wlan0 power off
> 
> Ivo

Hi,

I have exactly the same device /VID/. Ivo's suggestion fixed the problem, to some extent. Latency is fine now but every now and then I'd get (DUP!) duplicated packets and I've isolated the problem only to 54G capable APs. APs with 11n work fine without duplicate packets (or high latency).

My request is, will you please try pinging both G and N APs to see if duplicate packs are occurring at your end.

Walter

Re: 2.6.38: rt2800usb: high latency (1000ms)?

[Marc Dietrich]

Hello Ivo,

Am Mittwoch 13 April 2011, um 17:59:07 schrieb Ivo Van Doorn:
> Hi,
> 
> > I recall using this driver in staging and it crashing my machine, now
> > thats its no longer in staging, I thought I'd give it another try..
> >  Using the
> 
> The rt2800usb was not in staging but has been inside the main kernel
> tree for quite
> some time already, the alternative rt2870sta was in staging and will
> be removed very soon.
> 
> > following wireless usb adapter, I'm seeing very high latency when using
> > the device in Linux, (with Windows, there are no problems).  Using Debian
> 
> > Testing + wpa_supplicant, using the following USB adapter:
> Can you try disabling powersaving?
> iwconfig wlan0 power off

this doesn't helps with the ping times here and it also doesn't prevent the 
network traffic to stall from time to time (e.g. using apt-get install <some 
package>). 

Additionaly I found the following in the log:

[ 2701.455472] phy0 -> rt2x00usb_watchdog_tx_dma: Warning - TX queue 0 DMA timed 
out, invoke forced forced reset
[ 2701.655222] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to 
flush
[ 2702.461590] phy0 -> rt2x00usb_watchdog_tx_dma: Warning - TX queue 0 DMA timed 
out, invoke forced forced reset
[ 2702.655224] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to 
flush
[ 2703.455119] phy0 -> rt2x00usb_watchdog_tx_dma: Warning - TX queue 0 DMA timed 
out, invoke forced forced reset
[ 2703.655072] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to 
flush
[ 2704.454070] phy0 -> rt2x00usb_watchdog_tx_dma: Warning - TX queue 0 DMA timed 
out, invoke forced forced reset
[ 2704.645024] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to 
flush

This is with latest driver (rt2x00 master from today) backported to 2.6.37. The 
machine is arm tegra and the chip is a rt3070. Output of ping with "power off":

marc@ac100:~$ sudo ping -i 0.01 -s 1400 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 1400(1428) bytes of data.
1408 bytes from 192.168.10.1: icmp_req=1 ttl=64 time=10.9 ms
1408 bytes from 192.168.10.1: icmp_req=2 ttl=64 time=24.4 ms
1408 bytes from 192.168.10.1: icmp_req=3 ttl=64 time=6.72 ms
1408 bytes from 192.168.10.1: icmp_req=4 ttl=64 time=25.7 ms
1408 bytes from 192.168.10.1: icmp_req=5 ttl=64 time=7.01 ms
1408 bytes from 192.168.10.1: icmp_req=6 ttl=64 time=22.7 ms
1408 bytes from 192.168.10.1: icmp_req=7 ttl=64 time=9.07 ms
1408 bytes from 192.168.10.1: icmp_req=8 ttl=64 time=25.7 ms
1408 bytes from 192.168.10.1: icmp_req=9 ttl=64 time=6.07 ms

1408 bytes from 192.168.10.1: icmp_req=10 ttl=64 time=1931 ms
1408 bytes from 192.168.10.1: icmp_req=11 ttl=64 time=1920 ms
1408 bytes from 192.168.10.1: icmp_req=12 ttl=64 time=1917 ms
1408 bytes from 192.168.10.1: icmp_req=13 ttl=64 time=1897 ms
1408 bytes from 192.168.10.1: icmp_req=14 ttl=64 time=1878 ms
1408 bytes from 192.168.10.1: icmp_req=15 ttl=64 time=1858 ms

1408 bytes from 192.168.10.1: icmp_req=16 ttl=64 time=23.2 ms
1408 bytes from 192.168.10.1: icmp_req=17 ttl=64 time=11.6 ms
1408 bytes from 192.168.10.1: icmp_req=18 ttl=64 time=23.9 ms
1408 bytes from 192.168.10.1: icmp_req=19 ttl=64 time=7.26 ms
1408 bytes from 192.168.10.1: icmp_req=20 ttl=64 time=22.6 ms
1408 bytes from 192.168.10.1: icmp_req=21 ttl=64 time=4.46 ms
1408 bytes from 192.168.10.1: icmp_req=22 ttl=64 time=25.8 ms
1408 bytes from 192.168.10.1: icmp_req=23 ttl=64 time=10.6 ms
1408 bytes from 192.168.10.1: icmp_req=24 ttl=64 time=23.2 ms
1408 bytes from 192.168.10.1: icmp_req=25 ttl=64 time=4.15 ms
1408 bytes from 192.168.10.1: icmp_req=26 ttl=64 time=21.5 ms
1408 bytes from 192.168.10.1: icmp_req=27 ttl=64 time=6.64 ms
1408 bytes from 192.168.10.1: icmp_req=28 ttl=64 time=21.6 ms

1408 bytes from 192.168.10.1: icmp_req=29 ttl=64 time=1792 ms
1408 bytes from 192.168.10.1: icmp_req=30 ttl=64 time=1811 ms
1408 bytes from 192.168.10.1: icmp_req=31 ttl=64 time=1794 ms
1408 bytes from 192.168.10.1: icmp_req=32 ttl=64 time=1774 ms
1408 bytes from 192.168.10.1: icmp_req=33 ttl=64 time=1755 ms

1408 bytes from 192.168.10.1: icmp_req=34 ttl=64 time=23.4 ms
1408 bytes from 192.168.10.1: icmp_req=35 ttl=64 time=7.42 ms
1408 bytes from 192.168.10.1: icmp_req=36 ttl=64 time=26.1 ms
1408 bytes from 192.168.10.1: icmp_req=37 ttl=64 time=6.85 ms
1408 bytes from 192.168.10.1: icmp_req=38 ttl=64 time=21.9 ms
1408 bytes from 192.168.10.1: icmp_req=39 ttl=64 time=3.21 ms
1408 bytes from 192.168.10.1: icmp_req=40 ttl=64 time=22.5 ms
1408 bytes from 192.168.10.1: icmp_req=41 ttl=64 time=3.93 ms
1408 bytes from 192.168.10.1: icmp_req=42 ttl=64 time=24.3 ms
1408 bytes from 192.168.10.1: icmp_req=43 ttl=64 time=5.07 ms
1408 bytes from 192.168.10.1: icmp_req=44 ttl=64 time=21.8 ms
1408 bytes from 192.168.10.1: icmp_req=45 ttl=64 time=7.76 ms

1408 bytes from 192.168.10.1: icmp_req=46 ttl=64 time=1974 ms
1408 bytes from 192.168.10.1: icmp_req=47 ttl=64 time=1965 ms
1408 bytes from 192.168.10.1: icmp_req=48 ttl=64 time=1976 ms
1408 bytes from 192.168.10.1: icmp_req=49 ttl=64 time=1957 ms
1408 bytes from 192.168.10.1: icmp_req=50 ttl=64 time=1942 ms
1408 bytes from 192.168.10.1: icmp_req=51 ttl=64 time=1923 ms

1408 bytes from 192.168.10.1: icmp_req=52 ttl=64 time=42.9 ms
1408 bytes from 192.168.10.1: icmp_req=53 ttl=64 time=27.1 ms
1408 bytes from 192.168.10.1: icmp_req=54 ttl=64 time=14.0 ms
1408 bytes from 192.168.10.1: icmp_req=55 ttl=64 time=21.2 ms
1408 bytes from 192.168.10.1: icmp_req=56 ttl=64 time=5.41 ms
1408 bytes from 192.168.10.1: icmp_req=57 ttl=64 time=22.1 ms
1408 bytes from 192.168.10.1: icmp_req=58 ttl=64 time=32.3 ms
1408 bytes from 192.168.10.1: icmp_req=59 ttl=64 time=19.2 ms
1408 bytes from 192.168.10.1: icmp_req=60 ttl=64 time=4.30 ms
1408 bytes from 192.168.10.1: icmp_req=61 ttl=64 time=25.7 ms
1408 bytes from 192.168.10.1: icmp_req=62 ttl=64 time=5.91 ms
1408 bytes from 192.168.10.1: icmp_req=63 ttl=64 time=21.7 ms
1408 bytes from 192.168.10.1: icmp_req=64 ttl=64 time=6.75 ms
^C
--- 192.168.10.1 ping statistics ---
70 packets transmitted, 64 received, 8% packet loss, time 6668ms
rtt min/avg/max/mdev = 3.212/513.169/1976.893/826.940 ms, pipe 7

You can see a clear pattern within the ping times.

Hope this helps,

Marc

2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

Hi,

I notice periodic kernel crashes when using wireless.
Has anyone seen this using the rt2800usb driver?

When the host is on the LAN (supermicro+intel), there are zero crashes.
Since I don't have it in a location where I can use netdump over the 
LAN/wire, see the picture below for the kernel crash/OOPS on the console:

http://home.comcast.net/~jpiszcz/20110425/kernel_crash.jpg [1.2m]

Thoughts?

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Roland Dreier]

On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> I notice periodic kernel crashes when using wireless.
> Has anyone seen this using the rt2800usb driver?
>
> When the host is on the LAN (supermicro+intel), there are zero crashes.
> Since I don't have it in a location where I can use netdump over the
> LAN/wire, see the picture below for the kernel crash/OOPS on the console:
>
> http://home.comcast.net/~jpiszcz/20110425/kernel_crash.jpg [1.2m]

Unfortunately a lot of the crash has scrolled away.  Is there any way
you can change your console's text mode to, say, 50 lines so more info
is visible?

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Mon, 25 Apr 2011, Roland Dreier wrote:

> On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>> I notice periodic kernel crashes when using wireless.
>> Has anyone seen this using the rt2800usb driver?
>>
>> When the host is on the LAN (supermicro+intel), there are zero crashes.
>> Since I don't have it in a location where I can use netdump over the
>> LAN/wire, see the picture below for the kernel crash/OOPS on the console:
>>
>> http://home.comcast.net/~jpiszcz/20110425/kernel_crash.jpg [1.2m]
>
> Unfortunately a lot of the crash has scrolled away.  Is there any way
> you can change your console's text mode to, say, 50 lines so more info
> is visible?
>

Hi,

I will try and fix / increase the resolution and wait for the next crash and
update this thread with a new image when it crashes again.

Thanks.

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Mon, 25 Apr 2011, Roland Dreier wrote:

> On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>> I notice periodic kernel crashes when using wireless.
>> Has anyone seen this using the rt2800usb driver?
>>
>> When the host is on the LAN (supermicro+intel), there are zero crashes.
>> Since I don't have it in a location where I can use netdump over the
>> LAN/wire, see the picture below for the kernel crash/OOPS on the console:
>>
>> http://home.comcast.net/~jpiszcz/20110425/kernel_crash.jpg [1.2m]
>
> Unfortunately a lot of the crash has scrolled away.  Is there any way
> you can change your console's text mode to, say, 50 lines so more info
> is visible?
>

Hi,

It crashed again:
http://home.comcast.net/~jpiszcz/20110426/rt2800usb-crash2.jpg [1.1m]

Please let me know if this is enough output as I cannot increase the
resolution anymore on this monitor..  Also if you have any patches you would
like me to try, let me know as this seems to happen quite often, thanks!

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Tue, 26 Apr 2011, Justin Piszcz wrote:

>
>
> On Mon, 25 Apr 2011, Roland Dreier wrote:
>
>> On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <jpiszcz@lucidpixels.com> 
>> wrote:
>>> I notice periodic kernel crashes when using wireless.
>>> Has anyone seen this using the rt2800usb driver?
>>> 
>>> When the host is on the LAN (supermicro+intel), there are zero crashes.
>>> Since I don't have it in a location where I can use netdump over the
>>> LAN/wire, see the picture below for the kernel crash/OOPS on the console:
>>> 
>>> http://home.comcast.net/~jpiszcz/20110425/kernel_crash.jpg [1.2m]
>> 
>> Unfortunately a lot of the crash has scrolled away.  Is there any way
>> you can change your console's text mode to, say, 50 lines so more info
>> is visible?
>> 
>
> Hi,
>
> It crashed again:
> http://home.comcast.net/~jpiszcz/20110426/rt2800usb-crash2.jpg [1.1m]
>
> Please let me know if this is enough output as I cannot increase the
> resolution anymore on this monitor..  Also if you have any patches you would
> like me to try, let me know as this seems to happen quite often, thanks!
>
> Justin.
>
>
>

Hi,

I am trying a different driver now: rt2870sta
I've read a few reports this may be the 'proper' one to use.
So far so good, no lag or anything and I did not have to set power off
either.

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Larry Finger]

>
> I am trying a different driver now: rt2870sta
> I've read a few reports this may be the 'proper' one to use.
> So far so good, no lag or anything and I did not have to set power off
> either.

Driver rtl2870sta is not the proper one to use. In fact, a patch to delete 
rt2860sta and rt2870sta from the kernel was queued yesterday, and they will be 
gone by the time 2.6.40 is released.

New firmware for rt2800usb was just accepted into the linux-firmware git tree. 
Please obtain a copy and try it.

Larry

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Tue, 26 Apr 2011, Larry Finger wrote:

>> 
>> I am trying a different driver now: rt2870sta
>> I've read a few reports this may be the 'proper' one to use.
>> So far so good, no lag or anything and I did not have to set power off
>> either.
>
> Driver rtl2870sta is not the proper one to use. In fact, a patch to delete 
> rt2860sta and rt2870sta from the kernel was queued yesterday, and they will 
> be gone by the time 2.6.40 is released.
>
> New firmware for rt2800usb was just accepted into the linux-firmware git 
> tree. Please obtain a copy and try it.
>
> Larry
>

Hello,

With latest rt2800usb (and firmware from the git tree ~5 minutes ago)

Without wlan0 power off:

PING atomw (192.168.0.2) 56(84) bytes of data.
64 bytes from atomw (192.168.0.2): icmp_req=1 ttl=64 time=103 ms
64 bytes from atomw (192.168.0.2): icmp_req=2 ttl=64 time=106 ms
64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=99.7 ms
64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=102 ms
64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=98.5 ms
64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=9.74 ms
64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=217 ms
64 bytes from atomw (192.168.0.2): icmp_req=8 ttl=64 time=141 ms
64 bytes from atomw (192.168.0.2): icmp_req=11 ttl=64 time=13.2 ms
^C
--- atomw ping statistics ---
11 packets transmitted, 9 received, 18% packet loss, time 10003ms
rtt min/avg/max/mdev = 9.744/99.095/217.349/58.880 ms

With latest rt2800usb (and firmware from the git tree ~5 minutes ago)

With wlan0 power off:

PING atomw (192.168.0.2) 56(84) bytes of data.
64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=40.6 ms
64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=0.894 ms
64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=0.735 ms
64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=0.693 ms
64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=0.680 ms
^C
-- atomw ping statistics ---
7 packets transmitted, 5 received, 28% packet loss, time 6005ms
rtt min/avg/max/mdev = 0.680/8.723/40.615/15.946 ms

Switching back to rt2870sta, rt2800usb is unusable for me at this time.

With rt2870sta and the Media Link 150 / USB stick, (I have two, the problems
occur on both, using different USB ports as well using the rt2800usb driver)

$ ping atomw
PING atomw (192.168.0.2) 56(84) bytes of data.
64 bytes from atomw (192.168.0.2): icmp_req=1 ttl=64 time=1.07 ms
64 bytes from atomw (192.168.0.2): icmp_req=2 ttl=64 time=0.709 ms
64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=0.921 ms
64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=0.723 ms
64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=0.752 ms
64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=0.718 ms
64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=0.745 ms
64 bytes from atomw (192.168.0.2): icmp_req=8 ttl=64 time=0.787 ms
64 bytes from atomw (192.168.0.2): icmp_req=9 ttl=64 time=0.835 ms
64 bytes from atomw (192.168.0.2): icmp_req=10 ttl=64 time=0.878 ms
64 bytes from atomw (192.168.0.2): icmp_req=11 ttl=64 time=0.704 ms
^C
--- atomw ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10010ms
rtt min/avg/max/mdev = 0.704/0.804/1.074/0.111 ms

Flawless, I hope the issues can be worked out with the rt2800usb driver, or
someone keeps a backport of the rt2870sta driver, thanks!

Here is some debug output from when I was using rt2800usb:

[  102.432319] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 0
[  102.913430] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 1
[  103.876437] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 2
[  103.918554] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 3
[  103.924421] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 5
[  103.939051] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 7
[  103.944339] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 8
[  103.959539] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 9
[  103.964800] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 10
[  103.973788] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 13
[  103.978632] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 14
[  103.984294] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 16
[  103.989152] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 17
[  104.249186] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 19
[  104.254079] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 20
[  104.259670] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 23
[  116.706277] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  116.845043] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 24
[  122.706346] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  123.706360] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[  124.706329] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  126.706328] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  128.706301] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  129.706281] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[  130.706403] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[  153.706296] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[  162.706335] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Jano]

Justin Piszcz ha scritto:
>
>
> On Tue, 26 Apr 2011, Larry Finger wrote:
>
>>>
>>> I am trying a different driver now: rt2870sta
>>> I've read a few reports this may be the 'proper' one to use.
>>> So far so good, no lag or anything and I did not have to set power off
>>> either.
>>
>> Driver rtl2870sta is not the proper one to use. In fact, a patch to 
>> delete rt2860sta and rt2870sta from the kernel was queued yesterday, 
>> and they will be gone by the time 2.6.40 is released.
>>
>> New firmware for rt2800usb was just accepted into the linux-firmware 
>> git tree. Please obtain a copy and try it.
>>
>> Larry
>>
>
> Hello,
>
> With latest rt2800usb (and firmware from the git tree ~5 minutes ago)
>
> Without wlan0 power off:
>
> PING atomw (192.168.0.2) 56(84) bytes of data.
> 64 bytes from atomw (192.168.0.2): icmp_req=1 ttl=64 time=103 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=2 ttl=64 time=106 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=99.7 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=102 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=98.5 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=9.74 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=217 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=8 ttl=64 time=141 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=11 ttl=64 time=13.2 ms
> ^C
> --- atomw ping statistics ---
> 11 packets transmitted, 9 received, 18% packet loss, time 10003ms
> rtt min/avg/max/mdev = 9.744/99.095/217.349/58.880 ms
>
> With latest rt2800usb (and firmware from the git tree ~5 minutes ago)
>
> With wlan0 power off:
>
> PING atomw (192.168.0.2) 56(84) bytes of data.
> 64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=40.6 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=0.894 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=0.735 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=0.693 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=0.680 ms
> ^C
> -- atomw ping statistics ---
> 7 packets transmitted, 5 received, 28% packet loss, time 6005ms
> rtt min/avg/max/mdev = 0.680/8.723/40.615/15.946 ms
>
> Switching back to rt2870sta, rt2800usb is unusable for me at this time.
>
> With rt2870sta and the Media Link 150 / USB stick, (I have two, the 
> problems
> occur on both, using different USB ports as well using the rt2800usb 
> driver)
>
> $ ping atomw
> PING atomw (192.168.0.2) 56(84) bytes of data.
> 64 bytes from atomw (192.168.0.2): icmp_req=1 ttl=64 time=1.07 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=2 ttl=64 time=0.709 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=3 ttl=64 time=0.921 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=4 ttl=64 time=0.723 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=5 ttl=64 time=0.752 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=6 ttl=64 time=0.718 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=7 ttl=64 time=0.745 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=8 ttl=64 time=0.787 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=9 ttl=64 time=0.835 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=10 ttl=64 time=0.878 ms
> 64 bytes from atomw (192.168.0.2): icmp_req=11 ttl=64 time=0.704 ms
> ^C
> --- atomw ping statistics ---
> 11 packets transmitted, 11 received, 0% packet loss, time 10010ms
> rtt min/avg/max/mdev = 0.704/0.804/1.074/0.111 ms
>
> Flawless, I hope the issues can be worked out with the rt2800usb 
> driver, or
> someone keeps a backport of the rt2870sta driver, thanks!
>
> Here is some debug output from when I was using rt2800usb:
>
> [  102.432319] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 0
> [  102.913430] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 1
> [  103.876437] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 2
> [  103.918554] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 3
> [  103.924421] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 5
> [  103.939051] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 7
> [  103.944339] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 8
> [  103.959539] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 9
> [  103.964800] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 10
> [  103.973788] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 13
> [  103.978632] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 14
> [  103.984294] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 16
> [  103.989152] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 17
> [  104.249186] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 19
> [  104.254079] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 20
> [  104.259670] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 23
> [  116.706277] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  116.845043] phy0 -> rt2800_txdone_entry_check: Warning - TX status 
> report missed for queue 2 entry 24
> [  122.706346] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  123.706360] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 2 status timed out, invoke forced tx handler
> [  124.706329] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  126.706328] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  128.706301] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  129.706281] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 2 status timed out, invoke forced tx handler
> [  130.706403] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 2 status timed out, invoke forced tx handler
> [  153.706296] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 0 status timed out, invoke forced tx handler
> [  162.706335] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX 
> queue 2 status timed out, invoke forced tx handler
>
> Justin.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi Justin,
- I do not have this issue with rt2800usb:
:~$ modinfo rt2800usb
filename:       
/lib/modules/2.6.38-5-generic/updates/drivers/net/wireless/rt2x00/rt2800usb.ko
license:        GPL
firmware:       rt2870.bin
description:    Ralink RT2800 USB Wireless LAN driver.
version:        2.3.0
author:         http://rt2x00.serialmonkey.com
srcversion:     8A52B052043FF2C7E5A8B14
----------------------------------------------------------------------------------------
:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.2 LTS"
-----------------------------------------------------------------------------------------
jano:~$ ls -l /lib/firmware/rt2870.bin
-rw-r--r-- 1 root root 4096 2010-11-18 22:20 /lib/firmware/rt2870.bin
-----------------------------------------------------------------------------------------
:~$ ping -c 5 www.google.it
PING www.l.google.com (74.125.232.116) 56(84) bytes of data.
64 bytes from 74.125.232.116: icmp_seq=1 ttl=54 time=29.8 ms
64 bytes from 74.125.232.116: icmp_seq=2 ttl=54 time=36.0 ms
64 bytes from 74.125.232.116: icmp_seq=3 ttl=53 time=36.1 ms
64 bytes from 74.125.232.116: icmp_seq=4 ttl=54 time=38.6 ms
64 bytes from 74.125.232.116: icmp_seq=5 ttl=54 time=34.1 ms

--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 20355ms
rtt min/avg/max/mdev = 29.821/34.965/38.603/2.937 ms

-----------------------------------------------------------------------------------
:~$ ping -c 5 www.google.it
PING www.l.google.com (74.125.232.112) 56(84) bytes of data.
64 bytes from 74.125.232.112: icmp_seq=1 ttl=54 time=39.5 ms
64 bytes from 74.125.232.112: icmp_seq=2 ttl=53 time=36.8 ms
64 bytes from 74.125.232.112: icmp_seq=3 ttl=53 time=35.4 ms
64 bytes from 74.125.232.112: icmp_seq=4 ttl=53 time=38.6 ms
64 bytes from 74.125.232.112: icmp_seq=5 ttl=53 time=34.3 ms

--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 20385ms
rtt min/avg/max/mdev = 34.302/36.943/39.525/1.945 ms
----------------------------------------------------------------------------------

Bye Jano

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Tue, 26 Apr 2011, Justin Piszcz wrote:

>
>
> On Tue, 26 Apr 2011, Larry Finger wrote:
>
>>> 
>>> I am trying a different driver now: rt2870sta
>>> I've read a few reports this may be the 'proper' one to use.
>>> So far so good, no lag or anything and I did not have to set power off
>>> either.
>> 
>> Driver rtl2870sta is not the proper one to use. In fact, a patch to delete 
>> rt2860sta and rt2870sta from the kernel was queued yesterday, and they will 
>> be gone by the time 2.6.40 is released.
>> 
>> New firmware for rt2800usb was just accepted into the linux-firmware git 
>> tree. Please obtain a copy and try it.
>> 
>> Larry
>>

Hi,

Just an update, this driver has been solid so far:
rt2870sta

With the Media Link 150 USB stick, not a single crash yet--
The rt2800usb driver is laggy and crashes the kernel (as of 2.6.38.x)--
Is there a possiblity to get rtl2870sta into the mainline?
It is the best wireless driver I've used for Linux with various usb wifi
adapters--

# uptime
  19:44:28 up 4 days, 10:16,  2 users,  load average: 1.51, 1.56, 1.25

Justin.

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Larry Finger]

On 05/02/2011 06:46 PM, Justin Piszcz wrote:
> Just an update, this driver has been solid so far:
> rt2870sta
>
> With the Media Link 150 USB stick, not a single crash yet--
> The rt2800usb driver is laggy and crashes the kernel (as of 2.6.38.x)--
> Is there a possiblity to get rtl2870sta into the mainline?

Not a chance. As of 2.6.39, it is gone.

> It is the best wireless driver I've used for Linux with various usb wifi
> adapters--

That driver was in staging because it does not use mac80211, which is an 
absolute requirement for a new mainline driver. Keeping things like rt2870sta 
that contain their own MAC layer just bloats the kernel and has code persist 
that no one really understands.

Please try the version of rt2800usb from compat-wireless with the latest 
firmware. If it still crashes the kernel, then post the bugs.

Larry

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Walter Goldens]

> > Just an update, this driver has been solid so far:
> > rt2870sta
> > 
> > With the Media Link 150 USB stick, not a single crash
> yet--
> > The rt2800usb driver is laggy and crashes the kernel
> (as of 2.6.38.x)--
> > Is there a possiblity to get rtl2870sta into the
> mainline?
> 
> Not a chance. As of 2.6.39, it is gone.
> 
> > It is the best wireless driver I've used for Linux
> with various usb wifi
> > adapters--
> 
> That driver was in staging because it does not use
> mac80211, which is an absolute requirement for a new
> mainline driver. Keeping things like rt2870sta that contain
> their own MAC layer just bloats the kernel and has code
> persist that no one really understands.
> 
> Please try the version of rt2800usb from compat-wireless
> with the latest firmware. If it still crashes the kernel,
> then post the bugs.
> 
> Larry

I agree to some extent that rt2870sta performs better compared to rt2800usb, as of now. However, significant strides have been made towards improving the rt2800usb as it pertains to these chips and I'm sure in due time, problems will be resolved.

The staging driver had to be removed in part because it collided with the rt2800usb, which in essence constitutes a race condition between the two drivers. When you plug your USB dongle, both of them load and both of them try to service your chip. The result isn't pretty. You have to manually blacklist one to enable the other to operate properly.

Now, if you're bent on using the staging driver, you can always grab it from Ralink's web site and ignore the future default rt2800usb.


Walter

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Jools Wills]

in case it is useful:

I am currently using the vendor driver on a device I have (O2 Joggler).
The rt2800usb driver didn't work well and the staging rt2870sta driver
didn't seem to work with wireless N and users reported to me that it
drops the connection and is unreliable. The vendor driver does seem to
work best.

I made a debian package (using dkms) of the vendor driver on my joggler
ppa. tested working wiht 2.6.37/2.6.38

https://launchpad.net/~jools/+archive/joggler

note it doesn't automatically install the newer firmware so that will
need to be done manually.

Best Regards

Jools

Re: 2.6.38: rt2800usb: driver is crashing the kernel

[Justin Piszcz]

On Tue, 3 May 2011, Jools Wills wrote:

> in case it is useful:
>
> I am currently using the vendor driver on a device I have (O2 Joggler).
> The rt2800usb driver didn't work well and the staging rt2870sta driver
> didn't seem to work with wireless N and users reported to me that it
> drops the connection and is unreliable. The vendor driver does seem to
> work best.
>
> I made a debian package (using dkms) of the vendor driver on my joggler
> ppa. tested working wiht 2.6.37/2.6.38
>
> https://launchpad.net/~jools/+archive/joggler
>
> note it doesn't automatically install the newer firmware so that will
> need to be done manually.
>
> Best Regards
>
> Jools
>

Hi,

Tried 2.6.39, laggy, lots of errors, going to go back to 2.6.38 w/ rt2870sta.

[ 9514.700343] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9524.700306] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9526.700279] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9538.700270] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9539.700227] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9577.700342] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9579.700314] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9585.700238] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9595.700352] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9598.700314] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9598.869690] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 46
[ 9598.873113] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 47
[ 9598.877453] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 48
[ 9598.884587] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 49
[ 9598.889435] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 50
[ 9598.896697] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 51
[ 9598.901949] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 52
[ 9598.908197] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 53
[ 9598.911798] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 54
[ 9598.931461] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 55
[ 9599.700317] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9600.700287] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[ 9601.760057] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 62
[ 9601.764633] phy0 -> rt2800_txdone_entry_check: Warning - TX status report missed for queue 2 entry 63

$ ping atomw
PING atomw.internal.lan (1.1.1.1) 56(84) bytes of data.
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=3 ttl=64 time=1540 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=4 ttl=64 time=639 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=5 ttl=64 time=571 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=6 ttl=64 time=492 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=7 ttl=64 time=510 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=8 ttl=64 time=528 ms
64 bytes from atomw.internal.lan (1.1.1.1): icmp_req=9 ttl=64 time=538 ms
^C
--- atomw.internal.lan ping statistics ---
9 packets transmitted, 7 received, 22% packet loss, time 8004ms
rtt min/avg/max/mdev = 492.253/688.793/1540.319/350.472 ms, pipe 2

Is there a certain or driver one should use with a MediaLink USB adapter?
http://www.amazon.com/Medialink-Wireless-Adapter-802-11n-Compatible/dp/B002RM08RE

The rt2870sta works flawlessly with 2.6.38.
The rt2800usb is very problamtic.

Thanks,

Justin.