* Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices
@ 2011-11-12 17:00 Andreas Hartmann
2011-11-14 15:08 ` Helmut Schaa
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Hartmann @ 2011-11-12 17:00 UTC (permalink / raw)
To: users; +Cc: linux-wireless@vger.kernel.org
Hello,
as I already wrote some time ago, the rt2800usb module doesn't work very
well with WUSB600Nv2, e.g. (rt3572 chip). If it's on load, you get a lot
of warnings like these:
kernel: [357109.158376] phy0 ->rt2800usb_txdone_entry_check: Warning -
Data pending for entry 28 in queue 2
or:
kernel: [357109.158275] phy0 -> rt2800usb_txdone_entry_check: Warning -
TX status report missed for queue 2 entry 20
The throughput is very very bad (between 3 and 0 Mbits/s - 802.11n).
To get some more information about what's happening, I did an USB trace
and compared it with the rt3572sta driver from ralink.
First the outcome of the trace of the ralink driver (example - netperf
-t TCP_MAERTS -h server):
Packet- src->dst Data URB type URB ID
number
----------------------------------------------------------------------
7743 host -> 8.1 Request 24576 (0) Submit 41c0
7744 8.1 -> host 21840 bytes Complete 41c0 (response to 7743)
7745 host -> 8.1 Request 24576 (0) Submit b140
7746 8.1 -> host 21840 bytes Complete b140 (response to 7745)
7747 host -> 8.1 Request 24576 (0) Submit c5c0
7748 8.1 -> host 21840 bytes Complete c5c0 (response to 7747)
7749 host -> 8.1 Request 24576 (0) Submit 92c0
7750 8.1 -> host 21840 bytes Complete 92c0 (response to 7749)
7751 host -> 8.1 Request 24576 (0) Submit a440
7752 8.1 -> host 6240 bytes Complete a440 (response to 7751)
7753 host -> 8.1 Request 24576 (0) Submit fe40
7754 8.1 -> host 21840 bytes Complete fe40 (response zu 7753)
I could see a completely regular request/response behavior. Requested
are 24576 bytes, the response almost always is 21840 bytes. Throughput
is about 10 MBit/s.
The same trace with rt2800usb confuses me completely:
82998 host -> 8.1 Request 3860 (0) Submit 2cc0
...
83043 8.1 -> host 1560 bytes Complete 29c0
83044 host -> 8.1 Request 3860 (0) Submit 2bc0
83045 host -> 8.1 Request 3860 (0) Submit 2340
83046 host -> 8.1 Request 3860 (0) Submit 25c0
83047 8.1 -> host 1560 bytes Complete 2540
83048 host -> 8.1 Request 3860 (0) Submit 27c0
83049 host -> 8.1 Request 3860 (0) Submit 29c0
83050 host -> 8.1 Request 3860 (0) Submit 2540
....
83056 8.1 -> host 1560 bytes Complete 1e40 (response to 83050)
83057 8.1 -> host 1560 bytes Complete c640 (response to 83050)
83059 8.1 -> host 1560 bytes Complete f4c0 (response to 83050)
83060 8.1 -> host 1560 bytes Complete 4940 (response to 83050)
83061 8.1 -> host 1560 bytes Complete 3240 (response to 83050)
83062 host -> 8.1 Request 3860 (0) Submit 1e40
83063 host -> 8.1 Request 3860 (0) Submit c640
83064 host -> 8.1 Request 3860 (0) Submit f4c0
83065 host -> 8.1 Request 3860 (0) Submit 4940
83066 host -> 8.1 Request 3860 (0) Submit 3240
83068 8.1 -> host 1560 bytes Complete 7440 (response to 83066)
83070 host -> 8.1 Request 3860 (0) Submit 7440
83072 8.1 -> host 1560 bytes Complete 34c0 (response to 83070)
83073 8.1 -> host 1560 bytes Complete 0840 (response to 83070)
83074 host -> 8.1 Request 3860 (0) Submit 34c0
83075 host -> 8.1 Request 3860 (0) Submit 0840
83076 host -> 8.1 Request 3860 (0) Submit ddc0
83077 8.1 -> host 1560 bytes Complete c8c0 (response to 83075)
83078 host -> 8.1 Request 3860 (0) Submit c8c0
83079 host -> 8.1 Request 3860 (0) Submit 4bc0
83111 8.1 -> host 1560 bytes Complete ca40 (response to 83078)
83112 8.1 -> host 1560 bytes Complete c640 (response to 83078)
83116 host -> 8.1 Request 3860 (0) Submit ca40
83116 host -> 8.1 Request 3860 (0) Submit c640
83122 8.1 -> host 1560 bytes Complete c9c0 (response to 83117)
83123 host -> 8.1 Request 3860 (0) Submit c9c0
83125 8.1 -> host 1560 bytes Complete c5c0 (response to 83123)
The device gets bombed with tons of small requests (3860 bytes instead
of 24576) and sometimes, there can be seen an answer (1560 bytes instead
of 21840). Most of the requests seem not to be answered at all.
Another comparison: using the ralink driver, I could count about 2365
packets / s. With the rt2800usb driver, I could see about 15187 packets / s.
Could anybody please try to explain this behavior, or even better, fix
it (it looks really broken to me)?
Thank you,
kind regards,
Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices
2011-11-12 17:00 Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices Andreas Hartmann
@ 2011-11-14 15:08 ` Helmut Schaa
2011-11-14 18:26 ` Andreas Hartmann
0 siblings, 1 reply; 4+ messages in thread
From: Helmut Schaa @ 2011-11-14 15:08 UTC (permalink / raw)
To: Andreas Hartmann; +Cc: users, linux-wireless@vger.kernel.org
On Sat, Nov 12, 2011 at 6:00 PM, Andreas Hartmann
<andihartmann@01019freenet.de> wrote:
> Could anybody please try to explain this behavior, or even better, fix
> it (it looks really broken to me)?
AFAIK it is possible to aggregate multiple frames into one URB
for rt2800 USB devices. However, rt2800usb doesn't make use
of this yet while the legacy driver does. However, I don't think that
this is the cause for the poor performance you see ...
Helmut
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices
2011-11-14 15:08 ` Helmut Schaa
@ 2011-11-14 18:26 ` Andreas Hartmann
2011-11-17 19:20 ` Helmut Schaa
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Hartmann @ 2011-11-14 18:26 UTC (permalink / raw)
To: Helmut Schaa; +Cc: users, linux-wireless@vger.kernel.org
Hello Helmut,
Helmut Schaa schrieb:
> On Sat, Nov 12, 2011 at 6:00 PM, Andreas Hartmann
> <andihartmann@01019freenet.de> wrote:
>> Could anybody please try to explain this behavior, or even better, fix
>> it (it looks really broken to me)?
>
> AFAIK it is possible to aggregate multiple frames into one URB
> for rt2800 USB devices. However, rt2800usb doesn't make use
> of this yet while the legacy driver does.
Hmm, could this be the reason, why the device gets extremely hot during
operation, especially when used in monitor mode (with airmon-ng)?
Oh, I just remember, that during my "seven more packets" sniffing, the
monitor mode of this device stalled after a few minutes. Probably the
same reason why it doesn't work very well (respectively stalls
completely) during normal mode.
One more thing:
At the moment, the tcp data transfer stalls, no more usb packets can be
seen ... .
> However, I don't think that
> this is the cause for the poor performance you see ...
Is it normal, that the device gets fired up with submits without waiting
for any answers? The usb handling with the legacy driver is absolutely
regular (submit / complete / submit / complete), the handling with the
rt2800usb driver just looks totally messy to me (the urb ids of the
submit / completes don't fit any more, even the "complete" comes before
the "submit" (see package 83056 and 83062) ?!).
Thanks for your explanation,
Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Re: Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices
2011-11-14 18:26 ` Andreas Hartmann
@ 2011-11-17 19:20 ` Helmut Schaa
0 siblings, 0 replies; 4+ messages in thread
From: Helmut Schaa @ 2011-11-17 19:20 UTC (permalink / raw)
To: Andreas Hartmann; +Cc: users, linux-wireless@vger.kernel.org
Am Montag, 14. November 2011, 19:26:23 schrieb Andreas Hartmann:
> Hello Helmut,
>
> Helmut Schaa schrieb:
> > On Sat, Nov 12, 2011 at 6:00 PM, Andreas Hartmann
> > <andihartmann@01019freenet.de> wrote:
> >> Could anybody please try to explain this behavior, or even better, fix
> >> it (it looks really broken to me)?
> >
> > AFAIK it is possible to aggregate multiple frames into one URB
> > for rt2800 USB devices. However, rt2800usb doesn't make use
> > of this yet while the legacy driver does.
>
> Hmm, could this be the reason, why the device gets extremely hot during
> operation, especially when used in monitor mode (with airmon-ng)?
Interesting, maybe this is related, yes. Not sure though.
> Oh, I just remember, that during my "seven more packets" sniffing, the
> monitor mode of this device stalled after a few minutes. Probably the
> same reason why it doesn't work very well (respectively stalls
> completely) during normal mode.
>
> One more thing:
> At the moment, the tcp data transfer stalls, no more usb packets can be
> seen ... .
>
> > However, I don't think that
> > this is the cause for the poor performance you see ...
>
> Is it normal, that the device gets fired up with submits without waiting
> for any answers? The usb handling with the legacy driver is absolutely
> regular (submit / complete / submit / complete), the handling with the
> rt2800usb driver just looks totally messy to me (the urb ids of the
> submit / completes don't fit any more, even the "complete" comes before
> the "submit" (see package 83056 and 83062) ?!).
Unfortunately I don't know the rt2800 USB code very well but the tx status
handling was changed some time ago to read the TX_STA_FIFO register
asynchronously ...
Helmut
>
> Thanks for your explanation,
> Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-11-17 19:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-12 17:00 Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices Andreas Hartmann
2011-11-14 15:08 ` Helmut Schaa
2011-11-14 18:26 ` Andreas Hartmann
2011-11-17 19:20 ` Helmut Schaa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).