Beamforming

[sfx2000]

Beamforming can help out in the middle ranges, out of the edge, the limiting factor is the client device transmitter...

As rmerlin suggested, some devices may have issues - Beamforming support is not a mandatory feature in 11n, and there are many ways to do it - including not doing it - the AP is the one that makes the decision to attempt, not the client.

With HT mode (11n), Beam Forming comes with a cost - as most of the chipsets back in the day could either do spatial multiplexing (this is how we get 2 and 3 streams) or Transmit Beamforming, not both... so again, many clients just don't acknowledge the request, as it can impact performance for that client.

In VHT mode - Beamforming co-exists with SM, and again, the AP starts by sending a sounding request - how it makes that decision is largely implementation - and the client can respond accordingly, if it's configured to do so..

Beamforming at most, brings about 2 to 3 dB advantage on the link from the AP to the client, and it's only applied in that direction, so again, the client really is the limiting factor.

If one isn't seeing much benefit from testing with and without, I would suggest turning it off, as it does increase the workload of the wifi chipsets in the AP, and this will add some latency as it has to do the calculations on how to phase the radios to target the beam.

 

[sfx2000]

If one wants to live dangerously, and has an RT-AC68U, you can try this...

Go into Professional, and disable Beamforming first - and then read the nvram settings for the items below - write them down... (actually if you can relay them back, as I don't have a 68U to test this against)

Going thru the code, one wants to disable implicit beam-forming for wl0, the 2.4G radio, along with HT mode in the 5G radio, only allowing the VHT mode to work for TxBF

nvram set wl0_itxbf=0
nvram set wl1_itxbf=0
nvram set wl1_txbf=1
nvram commit
reboot
​

if this works, then a small change can be made in the following path - just flip the booleans there... this is all spooky stuff, because I've been reviewing asuswrt for about a day...

~/asuswrt-merlin/release/src/router/www/Advanced_WAdvanced_Content.asp

if('<% nvram_get("wl_unit"); %>' == '1' || '<% nvram_get("wl_unit"); %>' == '2'){ // 5GHz up
if( based_modelid == "RT-AC3200" || based_modelid == "RT-AC69U" ||
based_modelid == "RT-AC56S" || based_modelid == "RT-AC56U" ||
based_modelid == "RT-AC68U" || based_modelid == "RT-AC68U_V2" || based_modelid == "DSL-AC68U" ||
based_modelid == "RT-AC87U" || based_modelid == "EA-AC87" ||
based_modelid == "RT-AC88U" || based_modelid == "RT-AC3100" ||
based_modelid == "RT-AC5300")
{
document.getElementById('wl_txbf_desc').innerHTML = "802.11ac Beamforming";
inputCtrl(document.form.wl_txbf, 1);

/* flip wl_itxbf bit to zero in the webform, and this should disable HT mode beamforming still allowing VHT mode to work */​

inputCtrl(document.form.wl_itxbf, 1);
}
​

 

[john9527]

/* flip wl_itxbf bit to zero in the webform, and this should disable HT mode beamforming still allowing VHT mode to work */
inputCtrl(document.form.wl_itxbf, 1);

Actually, this is only setting the display of the option in the gui.....so the option is already there. Just set universal beamforming to disable, 802.11ac beamforming to enable, to do what you want.

 

[chris.at]

I did a test at the edge of my wifi coverage in my garden (RT-68U, Samsung Galaxy S4, 802.11n 2,4 GHz) and can confirm that beamforming works and improves speed alot (in some situations). I have a 30 Mbps DSL line and without universal beamforming enabled I get about 5 Mbps incl. total link drops. When I enable it I get about 20 Mbps at the same location and a stable link. To be sure I tried it several times with and without universal beamforming enabled and the results were always the same - so if you don't have any problems you should leave it enabled.

Regards,
Chris

 

[sfx2000]

Well, I'm still stepping thru the code, I've been looking at this for a bit more than a day...

There's a lot of legacy stuff in there that goes way back, and they're trying to support a lot of different chipsets and modes - on the backend, there's a lot of nasty stuff that one doesn't want to touch - so going back to the front-end, the .asp page, we look at defaults, and there's a bunch of toggles...

I'm trying to help sort this, as VHT TxBF can be a good thing, but HT TxBF is troublesome - so if someone can go into Prof Settings, turn off the beamforming attributes, reboot, do the NV Read on the txbf vals, and then toggle them on, this would be very useful...

I don't have access to a Rt-AC68U to check it myself...

 

[kvic]

I have AC56U. Here are the corresponding nvram value changes under different GUI settings.
Maybe good to chase from where the nvram values changing to the actual effect applied to the wireless driver?

2.4G radio off
5G radio on; 802.11ac Beamforming “Enabled”; Universal Beamforming “Disabled”

NV ram values:

wl0_itxbf=0
wl0_txbf=1
wl0_txbf_bfe_cap=1
wl0_txbf_bfr_cap=1
wl0_txbf_imp=1
wl1_itxbf=0
wl1_txbf=1
wl1_txbf_bfe_cap=1
wl1_txbf_bfr_cap=1
wl1_txbf_imp=1
wl_itxbf=0
wl_txbf=1
wl_txbf_bfe_cap=1
wl_txbf_bfr_cap=1
wl_txbf_imp=1

2.4G radio off
5G radio on; 802.11ac Beamforming “Enabled”; Universal Beamforming “Enabled”

NV ram values:

wl0_itxbf=0
wl0_txbf=1
wl0_txbf_bfe_cap=1
wl0_txbf_bfr_cap=1
wl0_txbf_imp=1
wl1_itxbf=1
wl1_txbf=1
wl1_txbf_bfe_cap=1
wl1_txbf_bfr_cap=1
wl1_txbf_imp=1
wl_itxbf=1
wl_txbf=1
wl_txbf_bfe_cap=1
wl_txbf_bfr_cap=1
wl_txbf_imp=1

2.4G radio off
5G radio on; 802.11ac Beamforming “Disable”; Universal Beamforming “Disable”

NV ram values:

wl0_itxbf=0
wl0_txbf=1
wl0_txbf_bfe_cap=1
wl0_txbf_bfr_cap=1
wl0_txbf_imp=1
wl1_itxbf=0
wl1_txbf=0
wl1_txbf_bfe_cap=0
wl1_txbf_bfr_cap=0
wl1_txbf_imp=1
wl_itxbf=0
wl_txbf=0
wl_txbf_bfe_cap=0
wl_txbf_bfr_cap=0
wl_txbf_imp=1

 

[RMerlin]

There's a lot of legacy stuff in there that goes way back, and they're trying to support a lot of different chipsets and modes - on the backend, there's a lot of nasty stuff that one doesn't want to touch - so going back to the front-end, the .asp page, we look at defaults, and there's a bunch of toggles...

Now you see why I have to chose my battles... Between the large amount of uncommented code and its complexity, there's simply too much for one single person to figure out on his own within one lifetime.

 

[sfx2000]

I have AC56U. Here are the corresponding nvram value changes under different GUI settings.
Maybe good to chase from where the nvram values changing to the actual effect applied to the wireless driver?

Thx, that helps...

 

[sfx2000]

Now you see why I have to chose my battles... Between the large amount of uncommented code and its complexity, there's simply too much for one single person to figure out on his own within one lifetime.

Yep... I think eventually all SW ends up like this, esp. as time moves forward and more devices/developers are added - some might think that the jump from MIPS to ARM would have let them perhaps clean up and refactor, but that's balanced against time to market and having an existing code base to deploy...

Other vendors aren't any better in this regard...

To put things into perspective for non-programmers - this code base is like a game of Jenga, and moving the wrong block will bring the whole house down..

 

[sfx2000]

Now you see why I have to chose my battles... Between the large amount of uncommented code and its complexity, there's simply too much for one single person to figure out on his own within one lifetime.

FWIW - with the AsusWRT branches - I've sorted it, but the number of changes/patches here, and the work to merge things forward - nope... just not going there - too much work to maintain...

Going back to Asus however - if one has a direct feedback - Stop doing TxBF on HT - doesn't help out - just default to not doing it on single band and dual band devices across vendors, and VHT TxBF is a win in 5GHz only, back out of it on 2.4GHz.

 

[bodean]

Are we talking about both Explicit beamforming and Universal Beamforming here?

 

[sfx2000]

Are we talking about both Explicit beamforming and Universal Beamforming here?

Yep... and how it applies to 11n (HT) vs. 11ac (VHT) across the different bands (2.4 and 5).

11ac has a very specific and standard way of doing TxBF, but 11n is a big grey zone (many ways) and this causes some interop issues with different 11n clients...

Basically it ended up being a code review exercise, but to implement, there's too many changes potentially needed, and these would be to be merged forward - which puts a of effort on RMerlin for what is basically limited benefit.

 

[kvic]

FWIW - with the AsusWRT branches - I've sorted it, but the number of changes/patches here, and the work to merge things forward - nope... just not going there - too much work to maintain...

From the findings you got, which 802.11n clients will work reliably with AC56U/AC68U on universal beam forming?

 

[sfx2000]

From the findings you got, which 802.11n clients will work reliably with AC56U/AC68U on universal beam forming?

I haven't found one that reliably works across any/all AP vendors/chipsets - 11ac, that does...

 

[sfx2000]

I haven't found one that reliably works across any/all AP vendors/chipsets - 11ac, that does...

Just too unpredictable across the different client chipset vendors... and even then - blame it on the IEEE 802.11n working group for not agreeing on a single method to do TxBF...

 

[kvic]

Just too unpredictable across the different client chipset vendors... and even then - blame it on the IEEE 802.11n working group for not agreeing on a single method to do TxBF...

If we could have a small whitelist which is safe to turn on universal beam forming, with anything else turned off, it's still a win for merlin users. Maybe Asus should have done it, but perhaps they don't have the expertise in-house.

 

[Therion87]

Hate to bring up an old thread but, what was the suggestion here?

Disable both Beamforming options for 2.4GHz and enable 802.11ac Beamforming for 5GHz and disable universal on 5GHz?

 

[chamberc]

Hate to bring up an old thread but, what was the suggestion here?

Disable both Beamforming options for 2.4GHz and enable 802.11ac Beamforming for 5GHz and disable universal on 5GHz?

I think the general consensus is- try and find out on all accounts. It completely varies by device chipset of the client.

 

[chamberc]

So I got curious and decided to do some testing on this tonight. I have 70 or so devices that are regularly online throughout a 4400 square foot house.

I decided to just really test beamforming on the 2.4ghz band, as I only have about 10 5ghz devices.

First I set beamforming on (both universal and explicit) and rebooted the router, waited 5 minutes and then recorded all of the xmit/dwnlink speeds of each client.

Next I turned both types of 2.4ghz beamforming off and rebooted the router, waited 5 minutes and recorded the same information.

Unscientific conclusions:

40% of the 2.4ghz clients reported the same xmit/dwnlink speeds in both states (both beamforming ON & OFF)
20% of the 2.4ghz clients reported about 10% either lower xmit or dwnlink speeds with beamforming OFF
40% of the 2.4ghz clients reported either 10% higher xmit or dwnlink speeds with beamforming ON

My methodology in no way tests for connection stability and was just what I was willing to do tonight. For now, I'm leaving both types of 2.4 beamforming on based on the results. Results would also obviously be affected by other non-controlled conditions and may have nothing to do with the state of beamforming.

AC87 380.58beta1