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.
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
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.
> > 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
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
<[email protected]> wrote:
>
> On Wed, Apr 13, 2011 at 9:01 AM, Justin Piszcz <[email protected]> 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
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
> <[email protected]> wrote:
>>
>> On Wed, Apr 13, 2011 at 9:01 AM, Justin Piszcz <[email protected]> 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.
On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz <[email protected]> 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
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
On Wed, 13 Apr 2011, Daniel Halperin wrote:
> On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz <[email protected]> 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.
On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <[email protected]> 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
On Wed, 13 Apr 2011, Daniel Halperin wrote:
> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <[email protected]> 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
>
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 <[email protected]> wrote:
>
>
> On Wed, 13 Apr 2011, Daniel Halperin wrote:
>
>> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz <[email protected]>
>> 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
>
Hi!
> On Wed, 13 Apr 2011, Daniel Halperin wrote:
>
>> On Wed, Apr 13, 2011 at 10:57 AM, Justin Piszcz
>> <[email protected]> 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
Dear Daniel,
> On Wed, Apr 13, 2011 at 1:13 PM, Justin Piszcz<[email protected]> 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
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.
On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <[email protected]> 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?
On Mon, 25 Apr 2011, Roland Dreier wrote:
> On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <[email protected]> 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.
On Mon, 25 Apr 2011, Roland Dreier wrote:
> On Mon, Apr 25, 2011 at 11:35 AM, Justin Piszcz <[email protected]> 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.
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 <[email protected]>
>> 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.
>
> 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
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.
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 http://www.google.it
PING http://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
--- http://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 http://www.google.it
PING http://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
--- http://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
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.
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
> > 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
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
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.
