(testing) possibility of Beamforming?

[abroenni]

Hi

I have been poking around in the driver code when I noticed that the code had several references to Beamforming. But a iw phyX info only revealed the capability for SU-Beamformee. This is ok when the nic is used in managed mode. But in AP it would seem to be more useful to have SU-Beamformer capabilities. MU-Beamformer and MU-Beamformee would be even better for AP and managed mode.

I found the driver parameter rtw_beamform_cap:int and at first I did not know what integers it would accept. The following code fragement from os_dep/linux/os_intfs.c explains the int as a bit pattern:

/*
 298 * BIT0: Enable VHT SU Beamformer
 299 * BIT1: Enable VHT SU Beamformee
 300 * BIT2: Enable VHT MU Beamformer, depend on VHT SU Beamformer
 301 * BIT3: Enable VHT MU Beamformee, depend on VHT SU Beamformee
 302 * BIT4: Enable HT Beamformer
 303 * BIT5: Enable HT Beamformee
 304 */
 305 int rtw_beamform_cap = BIT(1) | BIT(3);

The Bit pattern 11 activates BIT0 and BIT1, which converted to a decimal int value is a 3. So, when I set rtw_beamform_cap=3 as a param, we actually get SU-Beamforming and SU-Beamformee in the capability output of iw. I then also tried to verify if that change actually made any difference, or if it is just words appearing on the screen. Using another wifi nic, I wiresharked the air for 8814au AP beacons and the SU-Beamformer and SU-Beamforee are mentioned. I have to look more into it if client devices actually make use of the function when upon conections.

But what would be more interesting would be to get MU-Beamforming working. regardless of what Bit converted value I add as a param, MU-capabilities are never shown. For instance: if one were to activate all the Bit related to Beamforming, would be 111111 as a bit pattern, and when converted to dec int it is 63. But this doesn't work.

Somewhere, in the beamforming code, I came cross a check for antenna count or stream count. But I did not understand it enough to be certain. I have a 4x4:3 device with 2 external rp-sma antennas and 2 internal ceramic antennas. The device is advertised, like most 8814au devices, as a 3T3R device. When the device is plugged in, I noticed debug entries that would declare the device as an 2T4R when probing the EEPROM (sorry, I dont have the logs on me at the moment). Maybe related?

Beamforming might not be that important afterall. This chip is falling out of favour anyways, but since I have it... Anyways, just wanted to share this. Cheers.

[morrownr]

Hi abroenni,

Quote: "But in AP it would seem to be more useful to have SU-Beamformer capabilities. MU-Beamformer and MU-Beamformee would be even better for AP and managed mode."

Reply: You are correct. I have not explored the Beamformer capabilities because I cannot find a way to get stable performance out of this driver in AP mode.

If you have figured out a way to get stable performance out of this driver in AP mode, please share.

Regards,

Nick

[morrownr]

@abroenni

I've been busy but am coming up for air. Where did you get with this issue?

I think it would be cool to have Beamformer since a lot of folks use this chipset for AP mode... at least since we now have AP mode fixed. Even SU-Beamformer would be better than nothing.

[abroenni]

Hi @morrownr

I have been testing out different things in the code, but I did not get much further than activating SU Beamforming using the setting rtw_beamform_cap=3. When using this module parameter, one can use vht_capab=...[SU-BEAMFORMER][SU-BEAMFORMEE] in hostapd config. Hostapd would then startup fine.

I never once got to point where my device would show MU-Beamforming capabilities. But I have seen it in other peoples' iw output. So I am not sure if this is solely depending on the driver or also on the device itself.

Could you try to add rtw_beamform_cap=63 (or =3) in your 8814au mod config, and start the accesspoint? Do you see any MU Beamforming? [Make sure to have the ap running first, or use the device in client mode connected to an AP, and then check. Some capabilities seem to only appear when the device is fully in use.]

[morrownr]

Quote: "Could you try to add rtw_beamform_cap=63 (or =3) in your 8814au mod config, and start the accesspoint?"

I tried what you requested. 3 gets SU Beamformer and SU Beamformee while 1 gets only SU Beamformer. I am going to dig into some of the other drivers here to see what I can figure out.

[abroenni]

Yeah, that's what I got. How do you go about figuring things like this out? I am adding RTW_INFO lines to the code as a means for being able to trace what is happening. However this is quite time consuming with all the recompiling, module loading and setting up the interface for testing/debugging. Or did you manage to setup a gdb with qemu for the kernel and module, so that you can do realtime debugging?

One more idea: Since your repos are being picked up by more distributions, would it make sense to have a dev branch [or 8814au-next or 8814au-future,...] for each? Sorta as a testing branch where changes can be applied, tested and if testing is successful, merge them into the main branch? This way them main branch remains stable throughout development.

[morrownr]

Quote: "How do you go about figuring things like this out?"

I do what you are doing. Read the code and play around with it. It isn't like Realtek has provided any documentation. Yes, it is very time consuming.

Quote: "would it make sense to have a dev branch [or 8814au-next or 8814au-future,...] for each?"

It might make sense but I just make a local copy separate from the main repo and play until I get results that I think are good to merge and I merge. I try to be very careful with the main repo. For the next two months or so I am going to be very busy and won't have time for setting up a separate repo but I can relook this issue when I do have time.

One thing that I am doing in the background is working to see if we can get a more recent version of the source. Will I be successful? I don't know. This driver is very fragile and hard to maintain compared to the other drivers located here so what we really need is a modernized, recent version of source. I went down the WPA3 rabbit hole and we just can't get there so we need Realtek to step up.

I don't like how poorly Realtek supports Linux users so I keep a repo with links and information about adapters that use in-kernel drivers:

https://github.com/morrownr/USB-WiFi

Pass the link on to others. I think most Linux users would be better off using usb wifi adapters that use in-kernel drivers and hopefully that repo can point them to the adapters that do use in-kernel drivers. I enjoy working on the Realtek drivers as a way to help fellow Linux users but I am not a fan of Realtek.

Lastly, I did some testing with Realtek adapters based on other chipsets. rtw_beamform_cap=5 turns on SU Beamformer, SU Beamformee and MU Beamformee with the 88x2bu driver and a 8812bu adapter that I have. No MU Beamformer. It appears to me that both the driver and the firmware inside the adapter have to have support for anything to show. Do you think I should add rtw_beamform_cap=3 to 8814au.conf and document it? Do you want to handle it and submit a PR?

[abroenni]

Let me run a few tests with rtw_beamform_cap=3 used in AP and STA mode to checkout its impact on speed. I will get back to you, maybe with a PR.

[morrownr]

Sure. If we can't find a benefit, we are wasting our time.

FYI, the following allows you to check settings:

$ grep [[:alnum:]] /sys/module/8814au/parameters/*

And remember, this is a bitwise thing: 16 8 4 2 1 ... 3 = 11, 4 = 100, etc.

[morrownr]

Here is some data from testing on a rtl8812bu adapter here:

Driver: 88x2bu

$ iw list

rtw_beamform_cap= (adapter default = 10)

0 = nothing 1 = SU Beamformer 2 = SU Beamformee 3 = SU Beamformer and SU Beamformee 4 = nothing 5 = SU Beamformer (no MU Beamformer ?)

8 = nothing

10= SU Beamformee and MU Beamformee 11= SU Beamformer and SU Beamformee and MU Beamformee

15= SU Beamformer and SU Beamformee and MU Beamformee (no MU Beamformer ?)

63= SU Beamformer and SU Beamformee and MU Beamformee (no MU Beamformer ?)

---

B5 B4 B3 B2 B1 B0 32 16 8 4 2 1

os_dep/linux/os_intfs.c explains the int as a bit pattern:

/ 298 BIT0: Enable VHT SU Beamformer 299 BIT1: Enable VHT SU Beamformee 300 BIT2: Enable VHT MU Beamformer, depend on VHT SU Beamformer 301 BIT3: Enable VHT MU Beamformee, depend on VHT SU Beamformee 302 BIT4: Enable HT Beamformer 303 BIT5: Enable HT Beamformee 304 / 305 int rtw_beamform_cap = BIT(1) | BIT(3);

---

My thoughts are that the firmware does not support MU Beamformer on this adapter.

[abroenni]

If we can't find a benefit, we are wasting our time.

I was asking that myself and I found this Beamforming Test report. In summary, beamforming has only some very conditional benefits. That is, when used in 5GHz for the range between 24-34ft and client and AP support beamforming. The article concludes that given the outlined conditions showed a 17% improvement with beamforming enabled. While that looks impressive, keep in mind that represents only a 4 Mbps average throughput gain in the test...To my surprise, it looks like beamforming can provide a slight performance improvement.

So, now we know the benefits side. Mind you that the tests where on comparatively better Access Points with respect to our 8814au USB dinghy.

[morrownr]

FYI: I have Realtek based adapters for all of the Realtek drivers here in the main site. That will allow me to test and compare numerous adapters so that we can hopefully see the big picture.

I did some testing last night with the 8812au driver. The default setting for this setup is rtw_beamform_cap=10 just like it was for the 8812bu I tested as seen above. It appears that Realtek goes with this setting (10) as default to allow the highest capability allowed in firmware for use in client (managed) mode. The 8812bu showed SU Beamformee and MU Beamformee but the older 8812au only showed SU Beamformee with the same default setting.

What did I see in my operational tests with the 8812au last night? I need more time to test from different distances and in different situations but from about 30 feet away and through one wall, and with iperf3 pounding away, it seems the link quality and signal level were slightly better when I changed to rtw_beamform_cap=0. So, to put it another way, disabling beamforming actually seemed to very slightly improve the the signal. My main fiber modem wireless router does support MU-MIMO and it is turned on.

It is early to throw out an opinion but I am leaning toward adding rtw_beamform_cap=0 to 8814au.conf and documenting it. The documentation will need to be clear. It can start with something like this:

0 = disabled 1 = SU Beamformer 2 = SU Beamformee 3 = SU Beamformer and SU Beamformee 10= SU Beamformee and MU Beamformee 11= SU Beamformer and SU Beamformee and MU Beamformee

The rest of the documentation to be determined.

What are your thoughts at this point? If we do add it and document it, we would likely start getting reports from other people.

[abroenni]

Did you actually see MU Beamformee/er capabilities with the 8814au chip? I never got to a point where it would display MU. So if you decide to add a section in the 8814au.conf, maybe just add

rtw_beamform_cap=0 0 = disabled 1 = SU Beamformer 2 = SU Beamformee 3 = SU Beamformer and SU Beamformee MU Beamformer/ee settings not supported

It would need to be different for the other drivers' conf files, as their chips may support some MU.

I have a 4-stream MU-MIMO router too, but when I have rtw_beamform_cap=3 (or 63) so that I activate SU-Ber/Bee, the router doesn't show these kinda flags for the connection (it does show MU-MIMO for others).

As a hint: When you test the connection and you set up an 8814au AP, consider adding require_vht=1 in hostapd.conf to force AC connections to the STAs (I think that's what it does), and also the vht_capab=...[SU-BEAMFORMER][SU-BEAMFORMEE] . For the other chips you should add [MU-BEAMFORMER][MU-BEAMFORMEE], but I think you know these settings anyways. Explicit Beamforming is an AC-5Ghz thing. Implicit Beamforming is for lower connections.

One more thing: check out this file: include/hal_ic_cfg.h. It defines chip config settings, amongst which is also beamforming. for 8814au it looks like

#ifdef CONFIG_RTL8814A
    #undef RTL8814A_SUPPORT
    #define RTL8814A_SUPPORT                1
    #ifndef CONFIG_FW_C2H_PKT
        #define CONFIG_FW_C2H_PKT
    #endif
    #define CONFIG_FW_CORRECT_BCN
    #ifdef CONFIG_BEAMFORMING
        #define BEAMFORMING_SUPPORT     1   /*for phydm beamforming*/
        #define SUPPORT_MU_BF               0
    #endif
    #define CONFIG_RTS_FULL_BW
#

The 0 for SUPPORT_MU_BF does not mean it is not supported, just used in a different way. Look where SUPPORT_MU_BF is used.

Other chips have this section instead

/*
     * Beamforming related definition
     */
    /* Only support new beamforming mechanism */
    #ifdef CONFIG_BEAMFORMING
        #define RTW_BEAMFORMING_VERSION_2
    #endif /* CONFIG_BEAMFORMING */

apparently, there are two beamforming versions in this driver, and the 8814au only uses the older one. Maybe thats why the other drivers show MU functionality. But I haven't found the section where the driver sets the BF capabilities, or where it gets it from. This is as far as if I am reading the code right, but I am not sure.

[morrownr]

Quote: "Did you actually see MU Beamformee/er capabilities with the 8814au chip?"

No. Read my reports carefully. One is about testing on 8812bu and the other is about testing on 8812au. I did those tests to get a better idea of what is going on. The best I can get out of the 8814au is: SU Beamformer and SU Beamformee.

Quote: "consider adding require_vht=1 in hostapd.conf to force AC connections to the STAs (I think that's what it does)"

I'm not so sure that I agree with your assessment of what require_vht=1 means. We may need to research it.

I haven't gotten to the point of digging into the code yet but what you are finding does not surprise me. My work on the 5 Realtek drivers here has led me to several conclusions. One conclusion is that this 8814au driver has not been modernized like some of the other drivers. The absolute best driver here is the 8812au. It is very modern by Realtek standards and is very stable. The code has had a lot of work that the others have not had. The worst driver is this one, the 8814au. It is not only bad but it is very fragile, which is one reason that you will see me being very careful about changes. The other drivers are somewhere in between. In the USB-WiFi repo in the area where I do a write up about these drivers, I recommend that Linux users do not buy adapters based on the 8814au or 8811au. We have 8814au based adapters already so we might as well play but Linux users seeking to spend new money would be wise to buy adapters based on the mt7612u or mt7610u chipsets. I have and use adapters based on those chipsets as well.

I am going to go ahead and merge the changes to 8814au.conf.