I'm seeing very slow receive rates (~63kb/s) with an EW-7811Un USB
adapter which appears to load the rtl8192cu driver. Is that a known
problem?
I'm currently running the Debian 2.6.39-rc7-amd64 kernel from unstable;
I believe rc7 may be the first Debian kernel to work with this adapter.
I also needed to patch Debian's firmware-realtek package to include the
relevant firmware as detailed here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625614.
With respect to the connection quality I see:
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=65/70 Signal level=-45 dBm
And during transfers "iw event -t" shows nothing other than the
occasional scan started/finished pair.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
On 05/14/2011 12:01 PM, Rob Browning wrote:
>
> I'm seeing very slow receive rates (~63kb/s) with an EW-7811Un USB
> adapter which appears to load the rtl8192cu driver. Is that a known
> problem?
>
> I'm currently running the Debian 2.6.39-rc7-amd64 kernel from unstable;
> I believe rc7 may be the first Debian kernel to work with this adapter.
>
> I also needed to patch Debian's firmware-realtek package to include the
> relevant firmware as detailed here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625614.
>
> With respect to the connection quality I see:
>
> Channel:1
> Frequency:2.412 GHz (Channel 1)
> Quality=65/70 Signal level=-45 dBm
>
> And during transfers "iw event -t" shows nothing other than the
> occasional scan started/finished pair.
You are using the correct firmware.
Could you please try the attached patch to see if it improves your throughput?
In addition, please file a Bugzilla report for this problem at
http:bugzilla.kernel.org.
Thanks,
Larry
On 05/15/2011 09:26 PM, Rob Browning wrote:
> Larry Finger<[email protected]> writes:
>
>> Could you please try the attached patch to see if it improves your
>> throughput?
>
> Certainly. Can I patch one of the linux-wireless trees, or should I get
> the source and build the whole kernel?
>
>> In addition, please file a Bugzilla report for this problem at
>> http:bugzilla.kernel.org.
You could patch either the linux-2.6 kernel (2.6.39-rc7), the wireless-testing
git tree, or get the source from your distro. You will have to build the entire
kernel as I do not have the necessary make files to build the driver as an out
of kernel module.
Larry
Larry Finger <[email protected]> writes:
> Could you please try the attached patch to see if it improves your
> throughput?
Certainly. Can I patch one of the linux-wireless trees, or should I get
the source and build the whole kernel?
> In addition, please file a Bugzilla report for this problem at
> http:bugzilla.kernel.org.
Will do.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
On 05/16/2011 12:18 AM, Rob Browning wrote:
> Larry Finger<[email protected]> writes:
>
>> You could patch either the linux-2.6 kernel (2.6.39-rc7), the
>> wireless-testing git tree, or get the source from your distro. You
>> will have to build the entire kernel as I do not have the necessary
>> make files to build the driver as an out of kernel module.
>
> That patch didn't seem to have an effect -- the receive rate still
> settles at about 60Kb/s.
>
> I patched the Debian linux-2.6 source package and rebuilt the kernel.
> The Debian kernel appeared to already have the wifi.h diff.
>
> Please let me know if I can help further.
Strange. With that patch in my system running with the current wireless-testing
kernel, I get 19.8 Mbps download and 17.3 Mbps upload using tcpperf. The box at
the other end is wired to my router/AP. The wireless connection is configured
for 270 Mbps, thus rtl8192cu is not driving it at full rates, but that
performance should be satisfactory.
Please run the following command for a couple of minutes to see what rate you get:
wget
http://ftp.utexas.edu/opensuse/factory/iso/openSUSE-NET-x86_64-Build0018-Media.iso
That mirror might not be the best one for you to use, but that should be the
best one to duplicate my results.
On my system, the instantaneous download rate ranges between 250 and 700 K/s.
Without the patch, the rate is 48 K/s.
Larry
I just tested Debian's 2.6.38-1 kernel, and it has the same problem,
though I just noticed something potentially interesting.
Right after booting the system, I started a wget which ran at a steady
800+K/s. Then I started an "lftp get -c" to grab a kernel image, and
both connections settled at about 400K/s.
After a minute or so, I killed the ftp connection; from then on all
transfers were limited to 60K/s.
Now that I think about it, that's consistent with what I've seen up to
this point.
Hope this helps
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Larry Finger <[email protected]> writes:
> Strange. With that patch in my system running with the current
> wireless-testing kernel, I get 19.8 Mbps download and 17.3 Mbps upload
> using tcpperf. The box at the other end is wired to my router/AP. The
> wireless connection is configured for 270 Mbps, thus rtl8192cu is not
> driving it at full rates, but that performance should be satisfactory.
>
> Please run the following command for a couple of minutes to see what rate you get:
>
> wget
> http://ftp.utexas.edu/opensuse/factory/iso/openSUSE-NET-x86_64-Build0018-Media.iso
So that command ran at essentially the rates you report for 10-20
seconds. Then I killed it and tried another test I'd been using, which
was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That
transfer started at a high rate, but settled fairly quickly at about
60KB/s. So I killed that transfer and restarted the wget, and it ran
steadily at ~60KB/s.
One question. While I'm fairly certain that I'm running your patch,
would there be an easy way for me to be certain? Perhaps I could add a
log message?
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[email protected]> writes:
> So that command ran at essentially the rates you report for 10-20
> seconds. Then I killed it and tried another test I'd been using, which
> was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That
> transfer started at a high rate, but settled fairly quickly at about
> 60KB/s. So I killed that transfer and restarted the wget, and it ran
> steadily at ~60KB/s.
In case it helps, it also looks like the 60KB/s is an aggregate limit.
Once it gets into the "lower bandwidth" state, if I run multiple
transfers, the total won't go above that.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Larry Finger <[email protected]> writes:
> You could patch either the linux-2.6 kernel (2.6.39-rc7), the
> wireless-testing git tree, or get the source from your distro. You
> will have to build the entire kernel as I do not have the necessary
> make files to build the driver as an out of kernel module.
That patch didn't seem to have an effect -- the receive rate still
settles at about 60Kb/s.
I patched the Debian linux-2.6 source package and rebuilt the kernel.
The Debian kernel appeared to already have the wifi.h diff.
Please let me know if I can help further.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
On 05/16/2011 10:57 PM, Rob Browning wrote:
> Rob Browning<[email protected]> writes:
>
>> So that command ran at essentially the rates you report for 10-20
>> seconds. Then I killed it and tried another test I'd been using, which
>> was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That
>> transfer started at a high rate, but settled fairly quickly at about
>> 60KB/s. So I killed that transfer and restarted the wget, and it ran
>> steadily at ~60KB/s.
>
> In case it helps, it also looks like the 60KB/s is an aggregate limit.
> Once it gets into the "lower bandwidth" state, if I run multiple
> transfers, the total won't go above that.
I can duplicate your result. To me, it appears to be a problem with bufferbloat.
If that is correct, then there is little I can do with rtl8192cu to fix the
problem. I see exactly the same slow rate with rt2800usb using an Ralink RT3070
device. In addition, I see that rate when connected to my router with a wired
100 Mbps connection.
What up/down rates do you see if you test with http://www.speedtest.net? I get 0.48
Mbps up and 12.03 Mbps down. The up rate is a little slower than the 512 Kbps
that my ISP provides. My nominal down rate is 7 Mbps with burst rates above 10
if the bandwidth is available. Apparently it was this morning.
Larry
Larry Finger <[email protected]> writes:
> I can duplicate your result. To me, it appears to be a problem with
> bufferbloat. If that is correct, then there is little I can do with
> rtl8192cu to fix the problem. I see exactly the same slow rate with
> rt2800usb using an Ralink RT3070 device. In addition, I see that rate
> when connected to my router with a wired 100 Mbps connection.
I suppose that's possible, but I get much higher rates (300K/s+) when
connecting to the same AP using the built-in wireless chipset (BCM4322)
from another, very similar laptop, and 6.0Mbps when testing from a third
client.
I also get 800K/s+ when running the wget command you suggested over a
wired connection to my primary router.
Unfortunately, can't double-check the second laptop's wireless rate
right now, but it got 300K/s+ for a long time, and I just tested the
6Mbps client. It was only when I migrated to the newer laptop and the
rtl8192cu usb adapter that I saw the much slower ~60K/s rate.
Thanks again
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[email protected]> writes:
> Next I'll try a different access point -- I'll let you know what I find.
> And if there's anything else I can do to help test, please let me know.
Instead, I was able to test an ath9k_htc based adapter (netgear n150),
which doesn't appear to have trouble in the same environment, but I'd
still prefer to use the much smaller rtl8192cu device if we can figure
out what's wrong.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[email protected]> writes:
> As another data point, I just tested the same device on a second machine
> (a desktop), and saw the same behavior -- initially high transfer rates
> trailing off to about 60K/s.
...and another data point. Just to be sure it wasn't that particular
usb device, I got another that I think is the same hardware (this time
the Airlink 101), and I see exactly the same behavior.
Next I'll try a different access point -- I'll let you know what I find.
And if there's anything else I can do to help test, please let me know.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[email protected]> writes:
> Rob Browning <[email protected]> writes:
>
>> So that command ran at essentially the rates you report for 10-20
>> seconds. Then I killed it and tried another test I'd been using, which
>> was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That
>> transfer started at a high rate, but settled fairly quickly at about
>> 60KB/s. So I killed that transfer and restarted the wget, and it ran
>> steadily at ~60KB/s.
>
> In case it helps, it also looks like the 60KB/s is an aggregate limit.
> Once it gets into the "lower bandwidth" state, if I run multiple
> transfers, the total won't go above that.
As another data point, I just tested the same device on a second machine
(a desktop), and saw the same behavior -- initially high transfer rates
trailing off to about 60K/s.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[email protected]> writes:
> Instead, I was able to test an ath9k_htc based adapter (netgear n150),
> which doesn't appear to have trouble in the same environment, but I'd
> still prefer to use the much smaller rtl8192cu device if we can figure
> out what's wrong.
Actually, I just realized I quoted the wrong model number above. The
device that works well is the WNA1100.
The rtl8192cu devices still struggle, after a short initial period of
reasonable behavior.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
On 06/07/2011 09:38 PM, Rob Browning wrote:
> Rob Browning<[email protected]> writes:
>
>> As another data point, I just tested the same device on a second machine
>> (a desktop), and saw the same behavior -- initially high transfer rates
>> trailing off to about 60K/s.
>
> ...and another data point. Just to be sure it wasn't that particular
> usb device, I got another that I think is the same hardware (this time
> the Airlink 101), and I see exactly the same behavior.
>
> Next I'll try a different access point -- I'll let you know what I find.
> And if there's anything else I can do to help test, please let me know.
It has been some time since you wrote this. Any changes?
I recently noticed a slow-down on my rtl8192cu doing TX TCP MAERTS tests with
netperf. The attached patch seemed to help. If you still have the problem, does
it help? Note: The patch is badly named - I started trying to fix a problem
connecting with a 270 Mpbs 2.4 GHz channel. It works with 150 Mbps. On the
higher speed network, it authenticates and associates, but no data gets through.
Larry