Rtl8812au: Recent commits degrade Archer T9UH connection speed

[SeeLook]

I'm using v5.3.4 for a few months on TP-LINK Archer T9UH (2357:0106)

• kernels form 4.20 till 5.0.7 for now (Arch Linux)

My latest update to git caused degrading speed dramatically (about 1/3 of previous values I used to)
Reverting to https://github.com/aircrack-ng/rtl8812au/commit/0eda114fda2b66682deff77b1259c0aa6d2e6206
(Added support for kernel v5.0+) brought things back - usual (hi) speed.

Any ideas?

Actually I'm using iwd and manual ip configuration (no networkmanager) but with wpa_supplicant and with NM there is the same situation.

[BytEvil]

Same issue on AWUS1900 on Archlinux kernel 4.14.90.

[SeeLook]

Found culprit:
https://github.com/aircrack-ng/rtl8812au/commit/7360779d5aa19854340359d4a34b85ba749fb330
After approving that patch wifi speed slows down.

Unfortunately this bunch of changes seems quite complicated to me to find myself what exactly is the liability.
So help, please.

[SeeLook]

I've just tried to simply revert this "problematic" commit:
$git revert 7360779
and the driver works as fast as before.

[BytEvil]

this is temporary workaround, not a fix ;)

[kimocoder]

So what in the commit does this?
Is it the use of the older I/O handler (CONFIG_MP_VHT_HW_TX_MODE) ?

The rest of it is basicly the code for injection capabilities. Could you check?

[BytEvil]

No difference between CONFIG_MP_VHT_HW_TX_MODE=yes or no, very slow speed in AP mode, in my case. No issues with 5.2.20 version.

[SeeLook]

I tried to applying this feral commit almost line by line.
So after patching with those "frame injecting routines":
https://github.com/aircrack-ng/rtl8812au/commit/7360779d5aa19854340359d4a34b85ba749fb330#diff-e6d38c601720a256d3d8f4838e59c368
in file hal/rtl8812a/usb/rtl8812au_xmit.c
the module slowed down.
And this is all about v5.3.4

[Hurricos]

Please show us the contents of /etc/modprobe.d/88XXau.conf, and of iw dev <interface> info with and without that commit.

In the first case - this might either change the default VHT value that the driver gets inserted as, or change the settings of the driver when it's put into mass production testing mode. Not sure, but you should test what may happen if you change that line in the makefile.

Please be sure to tell us as well exactly what your use-case is. From the looks of it you're using it as a client - I have noticed no comparable speed issues between v5.2.20 and v5.3.4.

[BytEvil]

cat /etc/modrobe.d/8814au.conf
options 88XXau rtw_vht_enable=2

iw dev wlp0s20u3u4 info

Interface wlp0s20u3u4
        ifindex 6
        wdev 0x100000001
        addr 00:c0:ca:a7:55:9d
        type AP
        wiphy 1
        channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz
        txpower 24.00 dBm

[Hurricos]

And without 7360779#diff-e6d38c601720a256d3d8f4838e59c368 ? Looks like you're right about the width being forcibly degraded, but on my own machine, I have no such problem.

Here's my /etc/modprobe.d/88XXau.conf:

options 88XXau rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1 rtw_vht_enable=2 \
rtw_ht_enable=1 rtw_led_enable=1 rtw_full_ch_in_p2p_handshake=1

Assuming you're on an x86 machine, try pulling down the default and run dkms-install.sh without modifying the Makefile at all (do modifications for Raspberry Pi if you need to).

[Hurricos]

@BytEvil I am expecting one of these adapters in the mail soon, and will be able to debug for myself.

[BytEvil]

Last working commit is 0eda114. Since commit 7360779 connection speed is very low (stable, about 10mbit). I don`t use any modifications in Makefile...

[Hurricos]

It also doesn't help that I am using a rtl8811au instead of rtl8814au.

I will have an Archer T9UH to fix before Friday. Try using my 88XXau.conf with all options.

[BytEvil]

@Hurricos thanks for help, but problem not solved with your modprobing options. Periodically hostapd won`t start with error: Failed to set beacon parameters.

[Hurricos]

I'll get back to you when I have the device to fix myself. Not sure why injection frames would be caught in any of the logic changes here, but what do I know.

One additional question - does iw dev wlp0s20u3u4 info show you with width: 80 MHz (VHT) before the offending commit, or did you just configure your hostapd or whatnot like that?

The comment from @SeeLook suggests a drop to about 1/3 in performance, which is also consistent with a drop from VHT to HT (433 theoretical -> 150 theoretical per chain). In that case, rather than being a conflict in generation --

oh, let me roll forward with your comments.

[BytEvil]

### IEEE 802.11n
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-3839][DSSS_CCK-40]

### IEEE 802.11ac
ieee80211ac=1
vht_oper_chwidth=0
vht_capab=[SHORT-GI-40][RXLDPC][TX-STBC-2BY1]
vht_oper_centr_freq_seg0_idx=0

I don`t use 80 MHz ac bandwidth.

[Hurricos]

Hmm, and yet you still experience the drop in performance. OK, thanks for the info - we'll see when I get the device.

[Hurricos]

@kimocoder I can't find the function referenced by this signature in commit 7360779.

Seems like a typo; should it not be rtl8812a rather than rtl8812eu_cal_txdesc_chksum? One hint is from this commit.

@BytEvil @SeeLook Please check out https://github.com/Hurricos/rtl8812au/tree/v5.3.4 - I added a commit which may patch this issue.

[BytEvil]

@Hurricos, your patch is for rtl8812au, not for rtl8814au, right? You need to patch /hal/rtl8814a/usb/rtl8814au_xmit.c Archer T9UH and AWUS1900 based on 8814au chip.

[Hurricos]

I'm aware that your chipset is rtl8814au. I would suspect I'd need to patch rtl8814 if the bug is present in it, but this was the only obvious bug I could find that that commit introduced. The rest is just shuffling around code. Looks like the other big code change is the removal of an include guard, which makes it plausible that it is actually passing this check under AP mode, which is strange. So my assumption was incorrect.

Your path probably has nothing to do with it since it's in a different commit that we know isn't causing this ... still, try merging and compiling and tell me what happens. Alternatively, if you'd like to be more thorough / more helpful to the debug process, run a plain make for me before and after the offending commit in the original branch, and diff the outputs.

I'm going to head to get some sleep. Thanks for keeping up :)

[kimocoder]

8814AU isn't the same as 8812AU HAL boys... It's dirty, old, mixed and shit. Sad but true

[Hurricos]

@BytEvil Received dongle. Can confirm the issue, and can confirm your commit fixes it when using T9UH. It was a good learning experience for me to see that the fix to aggregation actually changes whether aggregation actually occurs. Before your change, there was no TX agg, and so I could see individual data frames flying; afterwards, I could only see the RTS/CTS frames since my monitoring device is only 1x1.

Now I'm just curious what would be involved in getting MIMO to work ...

MIMO works, I'm just IRQ-bound on the router.

[BytEvil]

This is good, but i still don’t like it, because the speed is still low, 100 Mbps instead of 160 Mbps in my case now. This is due to the fact that frame injection affects AP mode, which is not really necessary. Need to ask @kimocoder, this is true?

[ilnurkhal]

I have the same issue with Archer T9UH on Ubuntu 19.04

[kimocoder]

Update to the newest branch v5.6.4.2, hopefully this issue should be resolved like many others.
However, if the problem still persists, feel free to open this issue again so we're noticed. Thanks!