From: Andreas Hartmann <andihartmann@01019freenet.de>
To: users@rt2x00.serialmonkey.com
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices
Date: Sat, 12 Nov 2011 18:00:06 +0100 [thread overview]
Message-ID: <4EBEA616.2020002@01019freenet.de> (raw)
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
next reply other threads:[~2011-11-12 17:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-12 17:00 Andreas Hartmann [this message]
2011-11-14 15:08 ` Try to narrow down the problem with rt2800usb and rt3572 based USB WLAN devices Helmut Schaa
2011-11-14 18:26 ` Andreas Hartmann
2011-11-17 19:20 ` Helmut Schaa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EBEA616.2020002@01019freenet.de \
--to=andihartmann@01019freenet.de \
--cc=linux-wireless@vger.kernel.org \
--cc=users@rt2x00.serialmonkey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).