Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor wireless performance on 4.9.* kernels #1866

Closed
Rand0mJ0e opened this issue Feb 28, 2017 · 16 comments
Closed

Poor wireless performance on 4.9.* kernels #1866

Rand0mJ0e opened this issue Feb 28, 2017 · 16 comments

Comments

@Rand0mJ0e
Copy link

Raspberry pi zero was working fine with 4.4.38 kernel. Upgraded to 4.9.13 and observed very poor wireless performance using RTL8192CU wireless adapter.

With 4.9.13 kernel:
wlan0 IEEE 802.11 ESSID:"CatHouse"
Mode:Managed Frequency:2.422 GHz Access Point: 20:AA:4B:90:0F:BE
Bit Rate=72.2 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr=2347 B Fragment thr:off
Power Management:off
Link Quality=45/70 Signal level=-65 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:45 Missed beacon:0
With 4.4.38 kernel:
wlan0 IEEE 802.11bgn ESSID:"CatHouse" Nickname:"WIFI@REALTEK"
Mode:Managed Frequency:2.422 GHz Access Point: 20:AA:4B:90:0F:BE
Bit Rate:144.4 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=100/100 Signal level=58/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Problem also exists on 4.9.11 on Raspberry pi 2.
Problem resolved by downgrading back to 4.4.38 or to any 4.4.x level.

@popcornmix
Copy link
Collaborator

@MrEngman
I wonder if you've seen any change in performance with RTL8192CU devices on the newer kernel?

@MrEngman
Copy link

MrEngman commented Feb 28, 2017

Hi @popcornmix ,

Sorry, I haven't used the RTL8192cu wifi with 4.9 so can't say.

However, I have notice some odd behaviour using out of tree 8812au or 8192eu wifi and various 4.9.xx kernels. With the 8812au driver using a 5GB AP running iperf and 4.4 kernels I get transfer rates of around 95MBits/s but sometimes using kernel 4.9 I am seeing less than half this rate, around 42MBits/s. Powering off the Pi and disconnecting the PSU then re-applying power and rebooting and then iperf may give the 95MBits/s transfer rate, but not always.

I'm fairly certain iwconfig shows the same parameters regardless of the transfer rate being achieved, especially the bit rate of 434Mb/s.

Could be a similar issue with the 8192cu I suppose. I'll try one and see what happens.

@MrEngman
Copy link

@popcornmix
Absolutely dreadful.

I've given up on trying to test the 8192cu wifi using Edimax EW-7811Un. Tried on a 2B and 3B (with inbuilt wifi disable) and even just trying to connect to the AP is almost impossible and my Pi's are within a metre or two from the AP.

Both Pi's using kernel 4.9.13-v7+ #972

Noticed the driver has been changed so I think you need to revert to the previous one. I'll have a look at trying that myself but not sure when I'll be able to.

@MrEngman
Copy link

MrEngman commented Mar 1, 2017

@popcornmix

Looks like there is a problem with the kernel compile causing an issue with the 8192cu wifi.

Doing a search through the modules directory there is the file ./realtek/rtl8192cu/8192cu.ko and also files ./realtek/rtlwifi/rtl8192cu/rtl8192cu.ko and ./rtlwifi/rtl8192c/rtl8192c-common.ko. Very odd.

I deleted the rtlwifi files and the Pi 2B is now working with the 8192cu wifi. So looks like there is an issue with configuring the kernel drivers to be compiled and a conflict between drivers seems to be causing the problems I had with the 8192cu wifi.

Before deleting the rtlwifi files lsmod shows

4.9.13-v7+ #972
pi@Pi-2B-a ~ $ lsmod
Module                  Size  Used by
snd_bcm2835            24427  0
snd_pcm                97226  1 snd_bcm2835
snd_seq                61570  0
snd_seq_device          5504  1 snd_seq
snd_timer              23840  2 snd_seq,snd_pcm
snd                    70032  5 snd_seq,snd_timer,snd_seq_device,snd_bcm2835,snd_pcm
arc4                    2211  2
rtl8192cu              81479  0
rtl_usb                12644  1 rtl8192cu
rtl8192c_common        59362  1 rtl8192cu
rtlwifi                88937  3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211              655288  3 rtl_usb,rtlwifi,rtl8192cu
cfg80211              542899  2 mac80211,rtlwifi
rfkill                 20851  2 cfg80211
bcm2835_gpiomem         3940  0
uio_pdrv_genirq         3923  0
uio                    10204  1 uio_pdrv_genirq
fixed                   3285  0

After deleting the rtlwifi files shown above lsmod shows

pi@Pi-2B-a ~ $ lsmod
Module                  Size  Used by
snd_bcm2835            24427  0
snd_pcm                97226  1 snd_bcm2835
snd_seq                61570  0
snd_seq_device          5504  1 snd_seq
snd_timer              23840  2 snd_seq,snd_pcm
snd                    70032  5 snd_seq,snd_timer,snd_seq_device,snd_bcm2835,snd_pcm
8192cu                582217  0
cfg80211              542899  1 8192cu
rfkill                 20851  2 cfg80211
bcm2835_gpiomem         3940  0
uio_pdrv_genirq         3923  0
uio                    10204  1 uio_pdrv_genirq
fixed                   3285  0

and the wifi is now working. Just deleted the rtlwifi files on the Pi 3B and that appears to be OK now as well.

NOTE: actually deleted the whole rtlwifi directory but I think it proves the point that there was a conflict between drivers or the rtlwifi driver doesn't work.

@Electron752
Copy link
Contributor

I just happened to notice this while browsing the web. I just want to make sure I'm innocent here and I didn't break anything.

I did submit a small change which added a header to the downstream only version to include a missing header on arm64. If it did break anything through, it should have only broken IPv6 which in my part of the world(US) isn't used much.

But based on the description, it sounds like the upstream version is being picked up and that is what's broken. I'm looking at the logs, and the upstream version still appears to be under fairly active development, so it wouldn't surprise me if it broke.

As long as I'm innocent, I'll leave this to the experts.

@paul-1
Copy link

paul-1 commented Mar 1, 2017

Both drivers are built by default in the Kconfig, one needs to be blacklisted by default. That being said, I was unable to get realtek/rtlwifi/rtl8192cu to work. Driver loads without error, however with an EDImax 7811un it would not connect to my access point. The driver 8192cu works mostly fine,

@MrEngman
Copy link

MrEngman commented Mar 1, 2017

@popcornmix

Taken another look at the 8192cu wifi driver issue and there are two 8192cu drivers in the 4.9.xx kernel. Checked all the 4.9 kernels available via rpi-update (with and without BRANCH=next) and all are affected.

The two drivers are ./drivers/net/wireless/realtek/rtl8192cu/8192cu.ko also used in previous kernel revisions and .drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko which has not been compiled in previous kernel revisions.

Trying to run an 8192cu wifi adapter on a Pi 3B (with inbuilt wifi disabled) without making any alterations to the modules and I found it pretty much impossible to even get a connection to my AP.

I then tried by removing one or other of the drivers. Initially I removed file .drivers/net/wireless/realtek/rtl8192cu/8192cu.ko then rebooted and the rtlwifi driver, rtl8192cu.ko driver loaded and the wifi ran. However I connect to the Pi via SSH over wifi and the connection was very, very, intermittent. I ran a test using iperf and the performance and connectivity was really bad. The test should take 10 seconds but due to connectivity it took much longer and transfer rates were dreadful.

Using realtek/rtlwifi/rtl8192cu/rtl8192cu.ko driver.

pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 57672 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-61.8 sec  5.75 MBytes   781 Kbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 57674 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-18.0 sec  6.25 MBytes  2.92 Mbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 57676 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.7 sec  8.00 MBytes  6.25 Mbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 57678 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-153.0 sec  6.50 MBytes   356 Kbits/sec

I then restored the ./realtek/rtl8192cu/8192cu.ko driver and removed the rtlwifi driver ./realtek/rtlwifi/rtl8192cu/rtl8192cu.ko and the file ./realtek/rtlwifi/rtl8192c/rtl8192c-common.ko and rebooted and the 8192cu driver loaded and the wifi ran fine with no obvious issues at all and the SSH connection was fine. I then ran a test using iperf similar to the previous test and found no problems.

Performance is consistent and connectivity using SSH looks reliable, unlike the rtlwifi rtl8192cu driver.

Using ./realtek/rtl8192cu/8192cu.ko driver

pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 46402 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  51.9 MBytes  43.3 Mbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 46404 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  56.0 MBytes  46.8 Mbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 46406 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  55.9 MBytes  46.0 Mbits/sec
pi@Pi-3B-a:~ $ iperf -c 192.168.16.10
------------------------------------------------------------
Client connecting to 192.168.16.10, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.16.11 port 46408 connected with 192.168.16.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  55.1 MBytes  46.0 Mbits/sec

For whatever reason the rtlwifi rtl8192cu driver has been enable in kernel 4.9. Compiling this driver should be disabled as in kernels 4.4 and earlier.

@paul-1

The rtlwifi driver was not compiled into the kernel in 4.4 and earlier kernels.

@popcornmix
Copy link
Collaborator

Check out this thread #1525 for discussion.
Some users prefer to use the upstream driver (even though it generates a lot of complaints).
The plan was to build both, but blacklist the upstream one by default. Users could edit the blacklist to switch.
Ping @XECDesign - is the blacklist file now included in raspbian?

@XECDesign
Copy link
Contributor

@popcornmix I don't think so. Will add it in a bit if it's not there. Sorry, I seem to have missed the pings from last year.

@popcornmix
Copy link
Collaborator

@Rakhisharma
For now can you run:

echo "blacklist rtl8192cu" | sudo tee /etc/modprobe.d/blacklist-rtl8192cu.conf

and reboot. That should blacklist the upstream module. This should become a default setting in the near future.

@XECDesign
Copy link
Contributor

@popcornmix is that the only module that needs to be blacklisted?

@ED6E0F17
Copy link

ED6E0F17 commented Mar 2, 2017

There is a third option that I have been using for this chipset: "rtl8xxxu", but that the module is not currently built. You might want to blacklist it anyway.

@popcornmix
Copy link
Collaborator

@clivem did also suggest adding /etc/modprobe.d/blacklist-rtl8xxxu.conf containing blacklist rtl8xxxu in the other thread.
So probably also worth adding that now, then we can also build that kernel module without risk.

@XECDesign
Copy link
Contributor

This change is in the apt repo now. RPi-Distro/raspberrypi-sys-mods@5c0adce

@Rand0mJ0e
Copy link
Author

Thank you for the quick response. Adding the blacklist resolved the issue.

@herrernst
Copy link

Also stumbled upon this today after upgrading the kernel from 4.4 to 4.9, I've solved it by installing raspberrypi-sys-mods which also installs the blacklist (amongst other things).

floion pushed a commit to balena-os/balena-raspberrypi that referenced this issue Jan 11, 2018
Currently the raspberry pi kernel builds both the out of tree 8192cu kernel module
and the in-tree rtl8192cu kernel module. We are shipping both drivers in our OS and
this has the effect of the Realtek Adapter 8192cu to not work at all.

So we need to blacklist one of these modules to make this wifi adapter work.
Considering the comments on the raspberrypi official repository,
raspberrypi/linux#1866
we will blacklist the upstream driver and stick with the out of tree module which seems
to yield better performance.

Signed-off-by: Florin Sarbu <florin@resin.io>
floion pushed a commit to balena-os/balena-raspberrypi that referenced this issue Jan 11, 2018
Currently the raspberry pi kernel builds both the out of tree 8192cu kernel module
and the in-tree rtl8192cu kernel module. We are shipping both drivers in our OS and
this has the effect of the Realtek Adapter 8192cu to not work at all.

So we need to blacklist one of these modules to make this wifi adapter work.
Considering the comments on the raspberrypi official repository,
raspberrypi/linux#1866
we will blacklist the upstream driver and stick with the out of tree module which seems
to yield better performance.

Signed-off-by: Florin Sarbu <florin@resin.io>
floion pushed a commit to balena-os/balena-raspberrypi that referenced this issue Jan 11, 2018
Currently the raspberry pi kernel builds both the out of tree 8192cu kernel module
and the in-tree rtl8192cu kernel module. We are shipping both drivers in our OS and
this has the effect of the Realtek Adapter 8192cu to not work at all.

So we need to blacklist one of these modules to make this wifi adapter work.
Considering the comments on the raspberrypi official repository,
raspberrypi/linux#1866
we will blacklist the upstream driver and stick with the out of tree module which seems
to yield better performance.

Signed-off-by: Florin Sarbu <florin@resin.io>
floion added a commit to balena-os/meta-balena that referenced this issue Feb 15, 2019
We will only have the out of tree module which allegedly
is more stable:
raspberrypi/linux#1866

The configs for disabling it were added but apparently
they were never applied.

Change-type: patch
Changelog-entry: Disable in-tree rtl8192cu driver
Signed-off-by: Florin Sarbu <florin@balena.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants