Poor network performance with rtl8xxxu module compared to rtl8192cu, rtl8192cu also behaves strangely (RTL8188CUS)
 

I have a Netis RTL8188CUS Wi-Fi Adapter which behaves strangely with both the rtl8192cu and rtl8xxxu modules in different ways. The kernel automatically loads both rtl8192cu and rtl8xxxu when the adapter is plugged in. When separating the two modules (i.e blacklisting one or the other), if I'm using rtl8192cu all I/O slows to a halt until the network becomes configured. Applications won't load and commands in the terminal won't run until its finished doing its thing. This can take up to 5 minutes and suspending is no longer possible. However, once all is said and done and I'm actually using it, the performance is what I normally would get. I don't have bouts where websites don't load or random lag spikes in games (this will make sense in a second).

On the other hand, if I use rtl8xxxu then it no longer slows down the system until the network is configured and suspend works fine. However, the network performance is quite bugged where every 30 seconds or so it gets "choked", websites don't load or if I'm in-game my ping skyrockets to 500+, causing it to be unplayable. Its my understanding that the rtl8xxxu is set to replace rtl8192cu and it doesn't hang my entire system up so it's what I use, but I'd like to know what causes the poor network performance and the solution since the former module doesn't have this problem.

What I've tried:

• Turning on parameters for rtl8xxxu that have helped others (this is what I have in /etc/modprobe.d/rtl8xxxu-options.conf):
  
  Code:

  ---

  options rtl8xxxu dma_aggregation=Y ht40_2g=Y

  ---

  I've also tried different values for dma_agg_timeout and dma_agg_pages, but it didn't make any difference.
• Turning off Network Manager's powersaving with "wifi.powersave=2"
• Using nmcli con edit to change 802-11-wireless.powersave from 0 (default) to 2 (disabled) for the device
• Ensuring "Power Management" is off in iwconfig

Here is the device in lsusb:

For future reference, Realtek don't support linux, the little software they do write is crappy, and you are always likely to have issues with them. They do sell their chips so cheap you could give them away in breakfast cereal packets, and they often end up in cheap usb wifi dongles. Avoid them. Spend a bit more. Anyone else is usually better. Even Mediatek & Ralink drivers generally work well.

That said, I wouldn't blacklist anything. It it wants half a dozen modules and works, let it have them.
If it doesn't work, check on github in case someone wrote one. Only download a driver that has recent commits. Some guys wrote a driver, got their job, and promptly forgot it. You compile that against the kernel source, and it ends up in a misc/ directory and is used like other modules. Then you can blacklist the duds.

I have two Realtek dongles, the other one was an RTL8188FU which worked fine with rtl8xxxu in kernels newer than 6.2 but the fuse seems to have gone bad and just times out now according to dmesg. On the other hand I bought this RTL8188CUS because its one of the few ones known to support FreeBSD well, but I didn't realize just how slow FreeBSD wifi networking is, so here I am on Linux again.

When I just let both load, I suffer from the issues that rtl8192cu has. In other words it completely locks up my system, and I have to unload the module which takes around 5 minutes (for reference I have a Ryzen CPU, its very unnatural) but the network does at least work fine then, the problem is I'm sacrificing the ability to suspend or reboot without it taking a God-awful amount of time. It was my understanding that rtl8192cu is an older driver which has its functionality being replaced with rtl8xxxu.

The only driver I could find is this one that hasn't been worked on in several years, and doesn't work on 6+ kernels: https://github.com/pvaret/rtl8192cu-fixes

Ok. There's drivers for both your devices on github. I checked. You're probably best compiling both drivers and testing both. Go for the driver with the most recent commits. You need the kernel source code for your kernel, and the symlink(s) in /lib/modules/<version_number>/ must point to the kernel source tree. Run depmod afterwards.

Tell yourself you deserve the trouble for buying Realtek :). Better look for any other supplier even if it means paying more. Qualcomm, Cypress and others make better supported stuff and don't raise a middle finger at Linux! I know for cheap dongles on Ebay or Amazon it can be bad.

Where are you seeing this?

So much for a help forum, forget it.

You're supposed to lift a finger yourself, you know. Can you not do a simple search for your wifi cards on github.com's main page?

I have looked for a solution long enough now that I felt I needed to actually ask for help! And this is the second time I've had you tell me to buy different hardware. I make sure what I get supports Linux as I don't use any other OS. In fact, the rtl8188fu worked fantastic using the rtl8xxxu module, but recently the EFuse stopped parsing:

Out-of-tree modules are really something I want to avoid, but to be clear I've already tried looking on GitHub because desperate times call for desperate measures and the most recent I could find, rtl8192cu-fixes, does not build on a contemporary kernel!

OK. For the RTL8192CU, try https://github.com/Rick-Moba/rtl8192cu updated a week ago.

The drivers for the rtl 8188cus, the drivers are all ancient. The last one was updated in 2020 to kernel 5.18. The usual thing is that the kernel headers change, so the source errors out. So I'd suspect that one of the kernel modules (rtl8xxx, rtlwifi) can provide support. Mind you, there was little change in 5.x --> 6.x kernels.

Bear in mind wifi devices are 802.11b,g, n or perhaps 802.11a capable.the b,g. & n are increasing speeds, and 802.11a is the fastest. An old device might not be 802.11n compatible. So your speed would slow, but that's ok on some old devices. You'll have to check they can both do.

I'd try thr rtl8192cu first.

Thanks, I didn't see that one. All the results from GH's front page were from over a year ago..

I made an XBPS template and it builds and works just fine! Though, I'll have to test it more before I assume this is solved.

Okay, I haven't had any of the aforementioned issues since I installed the 8192cu DKMS. This is performing as expected. It's solved. Thanks!

Hi, hunter0one.

I fixed some problems in rtlwifi/rtl8192cu recently. You should try it again with kernel 6.9. It should not take 5 minutes to configure the network anymore. I'm not sure about suspending, I didn't have any trouble with that with my RTL8192CU.

The lag spikes etc is due to bugs in rtl8xxxu. Where did you buy such an old chip in 2024? I would like one too, for my collection, then I could fix rtl8xxxu.

The only way you get "Fatal - failed to parse EFuse" from rtl8xxxu is if the first two bytes of the efuse don't have the magic value 0x8129. It sounds like your device broke somehow.

Hi Bitterblue.

I'll try to build 6.9 and get back to you. I was going to wait until it's actually released but I guess it wouldn't hurt.

I just got both on Amazon looking for cheap wifi chips. I know it's not the best place but Amazon's the only one I'm on.

https://www.amazon.com/Netis-Wireles...s%2C120&sr=8-1 Here's the one I have.

As for the RTL8188FU I can't find the listing anymore but there's a bunch with similar casing (black and red like this one).

I imagine it probably burnt out, overheating seems to be a problem with these little chips. I'll probably invest in some better adapter that also has bluetooth here soon but I hope this helps with improving rtl8xxxu. :-)

I'm happy to report back kernel 6.9.0-rc3 fixes my need for the 8192cu DKMS. I also removed my modprobe.d blacklist to see what would happen and while rtl8192cu and rtl8xxxu both load it works and performs as expected. Thank you!