AC66R No beam forming

[Eric Lieb]

I just noticed on 380.57 that there is no beam forming option under 5ghz for the ac-66r. Is this normal behavior? My router has been acting up (weaker signal) since the latest update and didnt know if this was a factor

 

[RMerlin]

The RT-AC66U does not support beamforming. Only the newer, ARM-based models do.

 

[Eric Lieb]

The RT-AC66U does not support beamforming. Only the newer, ARM-based models do.

That can't be true. The AC66R (like the AC68R) both advertise AiRadar which Asus advertises as Beamforming.

https://www.asus.com/us/Networking/RTAC66R/ - They specifically mention it including photos on the page

http://www.snbforums.com/threads/do...doned-support-for-the-ac66u.11568/#post-72229

You even mentioned back in 2013 that the AC66R would be getting beam forming.

 

[RMerlin]

That can't be true. The AC66R (like the AC68R) both advertise AiRadar which Asus advertises as Beamforming.

https://www.asus.com/us/Networking/RTAC66R/ - They specifically mention it including photos on the page

http://www.snbforums.com/threads/do...doned-support-for-the-ac66u.11568/#post-72229

You even mentioned back in 2013 that the AC66R would be getting beam forming.

In the source code Asus specifically display the option only for these models:

 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")

Also, keep in mind that AiRadar is a marketing name that englobes multiples techniques to improve range/coverage. I suspect that this AiRadar umbrella might include different technologies depending on the router platform involved. AiRadar was already advertised back to the RT-N66U days, before the beamforming technology was implemented in any model.

I vaguely remember that for a while (long ago), the setting was visible on other models, but it eventually got removed. I assume that was because those models didn't support it.

 

[Eric Lieb]

In the source code Asus specifically display the option only for these models:

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")

Also, keep in mind that AiRadar is a marketing name that englobes multiples techniques to improve range/coverage. I suspect that this AiRadar umbrella might include different technologies depending on the router platform involved. AiRadar was already advertised back to the RT-N66U days, before the beamforming technology was implemented in any model.

I vaguely remember that for a while (long ago), the setting was visible on other models, but it eventually got removed. I assume that was because those models didn't support it.

The AC66U/R 100% supports beamforming...

http://www.broadcom.com/press/release.php?id=s637241

All 5G WiFi solutions from Broadcom support the following features:

• 80 MHz channel bandwidth that is 2 times wider than current 802.11n solutions
• 256-QAM, a higher modulation scheme that increases data transfer efficiency
• Transmit and receive beamforming
• Low Density Parity Check (LDPC) Codes
• Space-Time Block Codes (STBC)

Broadcom's new 5G WiFi chips deliver better coverage and longer battery life in a small form factor that is interoperable and compatible with existing technologies.

• Beamforming helps steer content in the direction of the intended receiver, increasing reliability and extending range; this is well complemented by STBC and LDPC code support.

Asus may have removed it from the source because the 66u is discontinued? Is it possible to add it back?

 

[RMerlin]

Asus may have removed it from the source because the 66u is discontinued? Is it possible to add it back?

It would make no sense for them to disable a feature because a model was "discontinued". Also, that webui change occurred maybe 1-2 years ago, if not longer ago. It wasn't changed recently.

The other possibility I can think of is that maybe this chip only supports implicit but not explicit beamforming. The source code isn't clear there, it seems to default to implicit being enabled, regardless of the webui support.

In any case, it's ultimately handled by the wireless driver itself, which is closed source, and outside of my control. All the webui does is allow the user to change the nvram value, it's ultimately up to the wireless driver to do anything with it.

 

[Eric Lieb]

It would make no sense for them to disable a feature because a model was "discontinued". Also, that webui change occurred maybe 1-2 years ago, if not longer ago. It wasn't changed recently.

The other possibility I can think of is that maybe this chip only supports implicit but not explicit beamforming. The source code isn't clear there, it seems to default to implicit being enabled, regardless of the webui support.

In any case, it's ultimately handled by the wireless driver itself, which is closed source, and outside of my control. All the webui does is allow the user to change the nvram value, it's ultimately up to the wireless driver to do anything with it.

If it defaults to implicit enabled that is fine... here is the 5gh chip specs https://www.broadcom.com/products/wireless-connectivity/wireless-lan/bcm4360

 

[RMerlin]

I have no way of knowing for sure. Someone would probably need to analyze the broadcasted beacon with a wireless packet sniffer to know - assuming this capability is advertised in the beacon.

Tim did a review at some point to see what kind of impact beamforming had, and he found out it only provided a marginal performance boost for clients located at a middle range for the router. It didn't improve performance for either close or far clients. So I'd be surprised that it would be the source of any significant performance drop.

 

[A.D.]

I just noticed on 380.57 that there is no beam forming option under 5ghz for the ac-66r. Is this normal behavior? My router has been acting up (weaker signal) since the latest update and didnt know if this was a factor

You may want to search the forums here regarding asuswrt-merlin 380 vs 378. Note that ASUS did not publish a 380 based official firmware for the 66. Several observations were made and elsewhere it was mentioned that the driver changed in 380. There are two (or so) forks which (potentially among other changes) combine the 378 driver with 380 features.

I'm pretty sure that the AC66 does beam forming from my observations. Also, marketing may be BS sometimes, but ASUS has a reputation to lose regarding speed and range, also with non-ASUS clients.

I was told during a discussion that ASUS drives its core development for newer models, potentially dropping compatibility, and later merges the new developemnts with code for older models (if still supported). I concluded it would be best to stick to firmware versions which are based on ASUS code snapshots which officially support my device, unless I urgently need some new feature.

 

[highwire]

I vaguely remember that for a while (long ago), the setting was visible on other models, but it eventually got removed. I assume that was because those models didn't support it.

I have had a RT-AC66U since the beginning. The very early versions of the firmware exposed the "implicit beam forming" option in the 5GHz wireless settings. It eventually disappeared. I remember it did not actually seem to do anything.

 

[Eric Lieb]

You may want to search the forums here regarding asuswrt-merlin 380 vs 378. Note that ASUS did not publish a 380 based official firmware for the 66. Several observations were made and elsewhere it was mentioned that the driver changed in 380. There are two (or so) forks which (potentially among other changes) combine the 378 driver with 380 features.

I'm pretty sure that the AC66 does beam forming from my observations. Also, marketing may be BS sometimes, but ASUS has a reputation to lose regarding speed and range, also with non-ASUS clients.

I was told during a discussion that ASUS drives its core development for newer models, potentially dropping compatibility, and later merges the new developemnts with code for older models (if still supported). I concluded it would be best to stick to firmware versions which are based on ASUS code snapshots which officially support my device, unless I urgently need some new feature.

I have been seeing performance issues with 380... I may drop back down to 378 if they continue.

 

[sfx2000]

I have no way of knowing for sure. Someone would probably need to analyze the broadcasted beacon with a wireless packet sniffer to know - assuming this capability is advertised in the beacon.

TxBF is in the beacon - for HT mode (802.11n), there's a number of stanzas as to what type of BF is available - for VHT, SU/MU support, along with both Beamformer/Beamformee is also present.

That just indicates if TxBF is available or not - it's the association handshake that determines if BF is actually used - sounding requests in HT mode are hard to interpret, but but basically, it's a null packet with an action - VHT is much better about it...

Tim did a review at some point to see what kind of impact beamforming had, and he found out it only provided a marginal performance boost for clients located at a middle range for the router. It didn't improve performance for either close or far clients. So I'd be surprised that it would be the source of any significant performance drop.

Shouldn't be any drop of performance if enabled, as this all happens in the 802.11 WiFi chip space, so unless the chipset vendor has totally borked it - and I doubt that Broadcom has, much less QC-Atheros or Marvell, it should be fairly transparent - no improvement in close range, mid-far, it might help get an MCS step or two higher, but that also needs to be considered with all STA's within the BSS that the AP is hosting...

TxBF has some latency - between 0.5 to 2 seconds - for fixed/nomadic clients, it's not a problem, for Mobiles (think walking around on a VoIP session) it can be problematic.

Also - note that TxBF isn't a spot-light on the targeted client - with 3/4 radios in use in the AP, one can't really get that level of definition and timing/phase relationships - it's more like a wide-angle flood light...

For most folks - implicit HT beam forming should be disabled - mainly due to lack of clarity across different client chipset vendors - for VHT, Realtek defaults to off, but Intel and Broadcom, and I suspect QC_Atheros (I don't have a QCA client to check) explicitly support 802.11ac TxBF if the AP does...