ASUS AiMesh Reviewed

[thiggins]

Jim Salter took ASUS' AiMesh for a drive and found your mileage may vary...a lot!

Read on SmallNetBuilder

 

[sfx2000]

Interesting article - and good insight into AiMesh and the pro's and con's.

I think there's room for some tuning of parameters within the individual nodes, just like SmartConnect, where defaults generally work, but having the option to do some minor tweaks can make it work better...

I agree with one of the statements - and this reflects my experience with another Vendors (over in Cupertino) that 'extends' AP's - one root and two leaf nodes is about as far as one would want to push things, go beyond that and it can introduce instability, and eventually the whole collection can fall apart if WiFi is used for the backhaul.

 

[thiggins]

I think there's room for some tuning of parameters within the individual nodes, just like SmartConnect, where defaults generally work, but having the option to do some minor tweaks can make it work better...

I'm sure there are "tunings". Hell, people have been trying to figure our the right setting for Smart Connect ever since ASUS exposed many of its controls.

But you can't tune much stuff on purpose-built mesh Wi-Fi systems. You can't even separate bands on most all systems. If ASUS thinks it has a particular way to optimize AiMesh, then it should apply it automatically, as other vendors do.

 

[sfx2000]

I'm sure there are "tunings". Hell, people have been trying to figure our the right setting for Smart Connect ever since ASUS exposed many of its controls.

But you can't tune much stuff on purpose-built mesh Wi-Fi systems. You can't even separate bands on most all systems. If ASUS thinks it has a particular way to optimize AiMesh, then it should apply it automatically, as other vendors do.

The 'tuning' might be Asus work to do - the feature has been in beta for some time, and they're pushing this into devices that are almost at the legacy point.

I was trying to be gracious to a point - that Asus has introduced this capability into the market is interesting, as many of the devices that this has been retrofitted to have already been in the market for a long time - noted that one of the devices under test was a legacy RT-AC68U (@800Mhz, which is what 4, maybe 5 years old?).

 

[Jim Salter]

The 'tuning' might be Asus work to do - the feature has been in beta for some time, and they're pushing this into devices that are almost at the legacy point.

I was trying to be gracious to a point - that Asus has introduced this capability into the market is interesting, as many of the devices that this has been retrofitted to have already been in the market for a long time - noted that one of the devices under test was a legacy RT-AC68U (@800Mhz, which is what 4, maybe 5 years old?).

The selection of the RT-AC68U was pretty deliberate, and price-focused. That looked like about the least expensive AiMesh capable router on the list when I was evaluating - but it's still $140-$150 a pop. At those prices, a three-node AiMesh kit is already as expensive as the best mesh kits. Spending even more per node than that would be kinda gonzo.

 

[sfx2000]

The selection of the RT-AC68U was pretty deliberate, and price-focused. That looked like about the least expensive AiMesh capable router on the list when I was evaluating - but it's still $140-$150 a pop. At those prices, a three-node AiMesh kit is already as expensive as the best mesh kits. Spending even more per node than that would be kinda gonzo.

Still a good call - I'm sure that there's plenty of members that have upgraded from the RT-AC68U, and have kept the older Router/AP on the shelf as a ready service spare - AIMesh at least can put the older device back into use without having to make additional investment.

 

[Jim Salter]

Still a good call - I'm sure that there's plenty of members that have upgraded from the RT-AC68U, and have kept the older Router/AP on the shelf as a ready service spare - AIMesh at least can put the older device back into use without having to make additional investment.

It's also worth noting that expanding your ASUS router with one additional ASUS router is a clear, unquestionable win. Without even needing wired backhaul, a two-node AiMesh system handily beat the solo RT-AC1900P in all metrics and without fuss. It's only once you hit three or more nodes that things start getting wonky (and it's still entirely possible that three nodes in a star topology would not have been as problematic as this three-node bus topology was).

 

[sfx2000]

It's only once you hit three or more nodes that things start getting wonky (and it's still entirely possible that three nodes in a star topology would not have been as problematic as this three-node bus topology was).

It's a good value for those who have gear already - consider an RT-AC86U and the spare RT-AC68U, that's about a $400 plus investment that AIMesh extends - compared to a rip and replace with a $300 plus mesh system.

It's worth noting in the article, IMHO, as well as a list of the supported devices.

Side Note -- Star vs. Bus - The other vendor I mentioned up thread - they deploy their "extended" network in a star config, and there, it works well enough. Can only define one as the Root, and the others are children, and only connect to the root, can use either radio (2.4GH or 5Ghz, but not both on the same child - children can choose their own based on conditions - so Child -1 may be on 2.4, and Child-2 may be on 5GHz)

 

[Jim Salter]

Side Note -- Star vs. Bus - The other vendor I mentioned up thread - they deploy their "extended" network in a star config, and there, it works well enough. Can only define one as the Root, and the others are children, and only connect to the root, can use either radio (2.4GH or 5Ghz, but not both on the same child - children can choose their own based on conditions - so Child -1 may be on 2.4, and Child-2 may be on 5GHz)

Until recently, star was the only thing any of the mesh kits would do - and conventional "wisdom" was that more than one hop was a terrible idea.

Plume and Eero changed the game on that one; I was in that "conventional wisdom" camp myself until I saw the latency results when deploying their kits (and, later, an Orbi RBK-53) in a bus topo at my house. Of course, it's all about the backhaul spectrum management. Eero spectrum-hops at each link, shifting from 5 GHz to 2.4 GHz and back again. Plume generally does the same thing. And Orbi just brute-forces it by having a dedicated backhaul band; yeah the backhaul competes with itself, but when the backhaul is that beautiful QCA9984 4x4, you can afford to give up 60% of it if that means getting a shorter-range, higher-QAM, lower-retransmit link to your STA...

Not all the kits that can handle bus or tree topology do it well, though. Orbi, Eero, and Plume all do a good job with it. IIRC Velop handled it reasonably well also. Deco M5, though... blech. Yeah, it'll do it, but you ain't gonna like it.

 

[OzarkEdge]

My 2xRT-AC86U AiMesh cost me $280 in March. It helps to shop sales/rebates.

OE

 

[sfx2000]

And Orbi just brute-forces it by having a dedicated backhaul band; yeah the backhaul competes with itself, but when the backhaul is that beautiful QCA9984 4x4, you can afford to give up 60% of it if that means getting a shorter-range, higher-QAM, lower-retransmit link to your STA...

Don't get me started about Orbi - the bandwidth pig that it is - the hidden backhaul on 5GHz UINII-3, is replicated on 2.4GHz as well, which is pretty harmful in the ISM band when in camps in odd channels - at least there, the 2.4GHz hidden SSID is shared with the Child SSID's - the 5GHz children are limited to UNII-1 and UNII-2 with DFS rules

https://www.snbforums.com/threads/orbi-the-bandwidth-annihilator.47742/

Orbi really is brute force, and not very neighbor friendly - camps on band channels in ISM 2.4GHz so destroys at least two of the common 1/6/11 there, and pretty much takes up bandwidth on UNII-1 and UNII-3 in most places. In a dense environment like Apartments and Condos, Orbi isn't really the right answer, in suburban environments with single family homes, it's still not very friendly there...

anyways - in most of my rants - I do try to provide some backup into to justify things.

I haven't heard anything back from Netgear on the Orbi observations - including the various bugs I've observed on the 802.11 captures.

 

[sfx2000]

Plume and Eero changed the game on that one; I was in that "conventional wisdom" camp myself until I saw the latency results when deploying their kits (and, later, an Orbi RBK-53) in a bus topo at my house. Of course, it's all about the backhaul spectrum management. Eero spectrum-hops at each link, shifting from 5 GHz to 2.4 GHz and back again. Plume generally does the same thing.

A lot of the Plume/Eero magic is actually Qualcomm at the base layer - not saying anything bad about Plume/Eero, as they've done a lot of hard work at the application layer, and also developing and deploying a product, as well as the business of building things up from a startup - finding investors, and more importantly, finding customers in volume to get profitable..

 

[sfx2000]

Until recently, star was the only thing any of the mesh kits would do - and conventional "wisdom" was that more than one hop was a terrible idea.

Conventional Wisdom was and is quite smart - and it really comes down to the trust relationship between the AP and the STA.

Star is the least risky, and bus/tree are very risky...

One assumes that the DS is trusted - and for a single AP, the trust is explicit - when going into Mesh, it becomes implied, aka, a friend of a friend, and this is risky, because there's no assurance that the keys are even the same back - because the Client STA only auths to the local AP in consumer space, not all the way back, and this breaks the ESS trust relationship.

This was a problem in 802.11S, and was also a problem with 802.16J (Wimax Relay), and with Wimax Relay, everything was secured with certs like WPA2-Enterprise (but even more). And even then, it was a huge amount of passionate discussion and some hard feelings.

And WPA3 doesn't fix this concern...

 

[thiggins]

Until recently, star was the only thing any of the mesh kits would do - and conventional "wisdom" was that more than one hop was a terrible idea.

Sorry, Jim. I have to disagree. My mesh test process forces a "bus" configuration (I call it two-hop). The only product that did not initially support this was Orbi, because it used a router/extender architecture.

Orbi now supports multi-hop and Ethernet backhaul. But they seem to have had trouble getting it all working correctly, judging from posts.

 

[Jim Salter]

Sorry, Jim. I have to disagree. My mesh test process forces a "bus" configuration (I call it two-hop). The only product that did not initially support this was Orbi, because it used a router/extender architecture.

Orbi now supports multi-hop and Ethernet backhaul. But they seem to have had trouble getting it all working correctly, judging from posts.

I haven't tested Orbi ethernet backhaul, but I've tested its multi hop topology multiple times, and have had a client using multi hop Orbi in production for more than a year now. The multi hop is quite solid.

A few years ago, Orbi didn't do multi hop, amplifi claimed to do multi hop but absolutely would not do it when I attempted to test it, no matter what I did (they did eventually get it working several firmware updates later), luma wouldn't do it, and I think something else wouldn't as well. I did leave out eero when mentioning kits that handled multi hop topologies though; they always handled it but in earlier firmware versions(again, we're talking a few years ago) didn't handle it very well.

 

[Eric Goldsmith]

Thank you for the first truly in-depth review of AiMesh I’ve seen.

I noted that after upgrading to the most current firmware, you didn’t do a “factory reset” on any of the devices - a step that is universally touted in this forum as a requirement, and the first step in a any debugging.

I realize you purposely took “the laziest route possible”, but I can’t help but wonder if/how any of the test results would have changed.

Eric

 

[OzarkEdge]

I noted that you didn’t do a “factory rest” on any of the devices - a step that is universally touted in this forum as a requirement, and the first step in a any debugging.

Maybe that's it... we need to send our AiMesh routers back to the factory for a rest!

OE

 

[Eric Goldsmith]

Ughh, auto-correct. Fixed.

 

[Jim Salter]

While it's possible that a factory reset would have changed things, it's highly unlikely. All three routers were completely new-in-box prior to the beginning of this test.

It's also worth noting that if a factory reset is required, it could be initiated directly from software during the AiMesh initialization process itself - no need to require users to do one manually, let alone require it but not tell them it's required.

 

[chadster766]

I find the charts hard to understand in the review because no legend or list of what UOM is applied to which value is listed.