ASUS AiMesh Reviewed – SmallNetBuilder

Introduction

I’ve been praising mesh Wi-Fi kits that support the ability to mix-and-match, and add new nodes as time goes by and your needs change (or you discover that you underpurchased to begin with) for awhile now. ASUS has taken this concept a welcome step further with AiMesh, which is their branded way of describing doing the same thing with one or more routers.

A few ASUS AiMesh routers

Rather than buying a router and then figuring out “this isn’t enough, I need mesh” and having wasted the initial $150-$300 you spent, you can simply add more routers later to extend your network.

AiMesh is obviously a great idea. But what’s it really like to live with? Is it easy to set up, configure and maintain? Does it perform well? And how does it compare in pricing to purpose-built mesh kits?

To find the answers, I set up an ASUS RT-AC1900P in AiMesh router mode, and added two ASUS RT-AC68Us as AiMesh nodes. Both models feature identical upright chassis with three external antennas, a 3×3 dual-band Broadcom BCM4360 wifi chipset and dual-core Broadcom CPUs. The only real difference between the two is the CPU speed – the RT-AC1900P has a 1.4 GHz BCM4709C0, while the RT-AC68U has an 800 MHz BCM4708A0.

Initial Setup

Setting up my first AiMesh network was a pleasantly simple process. Since it had the fastest CPU, I elected to make my RT-AC1900P the main router for the AiMesh network. I first set it up as you would any router; I plugged it in, found its default Wi-Fi network, connected to it and browsed to the .1 IP address on the subnet it offered.

This walked me through the usual sort of wizard, during which I was asked to change the default username and password, change the Wi-Fi network name(s) and the password to access them. The setup wizard defaulted to a single SSID for the BCM4360’s 2.4 GHz and 5 GHz radios, with Smart Connect (band steering) enabled. This is, in my experience, the configuration most people want from their network gear. Unfortunately, band steering is something ASUS isn’t very good at yet, and that’s going to cause us some problems down the road.

Once I’d nexted my way through the initial setup wizard, waited for the RT-AC1900P to reboot (which is pleasantly quick compared to most consumer routers), connected to the new SSID and logged back in, I saw there was no AiMesh option offered on the Administration page under Operation Mode. I assumed, correctly, this meant that the shipping firmware predated this feature.

Heading off to the Administration page presented me with a semi-automatic firmware update option (it didn’t check for me, but had a button which would go search ASUS’ website for newer firmware once clicked). Clicking worked as expected; new firmware was found and installed, and after another reboot and router login, the missing “AiMesh” Operation Modes were available. I clicked “AiMesh Router”, and after another reboot, had an empty AiMesh Nodes section showing on the front page of the router UI.

I deliberately set up review kits differently than I do my own gear. When I’m setting up devices in production, I err on the side of making the configuration as easy on the designers (and therefore as likely to work the first time) as possible. When setting up devices for review, I do the exact opposite, and take the laziest route possible that seems the most likely to uncover a corner case the engineers didn’t think of.

So when I set up the first of my two RT-AC68U routers, and saw that it already had AiMesh options available, I didn’t update its firmware first – I just rushed straight into “AiMesh node” and waited to see what upgrading the firmware would look like after it was a part of my new AiMesh network. Returning to the RT-AC1900P, I clicked “Scan for AiMesh Nodes”, and it found and added my first node uneventfully.

Adding my first AiMesh Node was quick and easy

For the second RT-AC68U, I didn’t even do that much – I literally just plugged it in and ignored it. Worse, I plugged it in downstairs, hugging the back wall, where it would be able to see the upstairs AiMesh Node, but would not be able to see the AiMesh Router itself.

To my surprise and delight, when I returned to the RT-AC1900P and clicked “scan for AiMesh Nodes” again, it found and cheerfully added my second RT-AC68U to the network. This was despite the fact that I’d just pulled out of the box, plugged it in where the router itself wouldn’t be able to see it, and ignored any initial setup to put it in “AiMesh Node” operation mode specifically.

Adding the second AiMesh Node was also very easy

Upgrading the firmware on the two AiMesh Node routers turned out to be a little more frustrating, however. Once they’ve been added to your network, each Node shows up with its own icon on the front page of the AiMesh Router’s configuration screen. From there, you can see each Node’s IP address, and you can (and should!) give it a friendly alias. I named mine “Living room TV” and “Downstairs Den”.

What you can’t see is any sort of option to check or upgrade their firmware. The next step I tried was browsing to their IP addresses, as shown in the Node configuration. While they did answer my browser, all they did was HTTP 302 redirect me to the AiMesh Router’s own login page. Finally, I tried checking the AiMesh Router’s own firmware update page – and there they were.

Firmware upgrades are done from the AiMesh Router’s own firmware upgrade dialog

There’s still only a single button next to the AiMesh Router itself for “Check Firmware”, and it’s not clear from looking whether it will check and upgrade all three or only the router itself – but it does work, although a bit unpredictably. It took me three tries (and three reboots) of clicking the same button before it finally managed to upgrade the second RT-AC68U, but it eventually did get there, and all was well.

Configuration And Maintenance

Configuring an AiMesh network is, for the most part, exactly what most people would want it to be. You configure your AiMesh Router exactly as you’d normally configure it, and whatever settings you configure there are automatically passed down to the AiMesh Node router “children”.

ASUS has an admirably complete set of functions in their router interfaces, and I couldn’t find any of them missing after the RT-AC1900P was configured to AiMesh Router mode. It was the exact same router, only now I had three, all automagically configured the same way.

AiMesh’s central configuration management works well

Unfortunately, what you can’t do is configure your AiMesh nodes to use different Wi-Fi channels than your AiMesh router. Both 2.4 GHz and 5 GHz radios on all AiMesh nodes will be set to the same values as your AiMesh Router… even if you’ve got wired backhaul between the nodes and router. This maximizes airtime congestion in your network, since every single device can “hear” (and talk over) one another, and there’s nothing you can do about it.

A final note about maintenance. The identical chassis I mentioned in the introduction caused me some difficulties later on, as neither RT-AC68U nor RT-AC1900P showed the actual model number on the front of the chassis. Both simply state “AC1900 dual band router” on the front, and reserve the actual model number for the extremely fine, dull brown print on the back.

I usually physically label all devices in a mesh kit before I begin testing, but this time I skipped that step – and it bit me hard when I needed to set things up a second time after initially breaking them down. I had lost track of which device was which and spent an embarrassingly long and frustrated time trying to figure out why my RT-AC1900P AiMesh Router wasn’t recognizing its WAN connection! I finally realized I’d plugged one of the RT-AC68U AiMesh Nodes in its place. Learn from my mistakes! If you have any network kit involving multiple physically identical nodes, label them appropriately during the setup process!

Topologies

With a single router, there’s a single possible topology: one access point, with wired backhaul (meaning an Ethernet cable run from its WAN port to your Internet connection). Most people usually can’t even choose where to put the router, since “where the Internet comes in” is frequently not easily changed.

Moving to three routers/APs/nodes changes the playing field. Will you use a star topology (all child nodes connected directly to the router) or a bus topology (child 2 connects to child 1, which connects to the router)? Will you use wired backhaul (Ethernet cables leading from each node to the next hop closer to the Internet), or Wi-Fi backhaul? If you’re using Wi-Fi backhaul, will you use 5 GHz, 2.4 GHz, or both?

Mesh nodes can connect three ways

AiMesh takes some of these decisions away from you. You may use wired or Wi-Fi backhaul. But with Wi-Fi backhaul, you have no control over whether it selects 2.4 GHz or 5 GHz; AiMesh chooses. In my testing, my AiMesh Nodes were close enough that it felt comfortable with 5 GHz backhaul, so 5 GHz it was, whether I liked it or not.

This is a pretty simplistic selection algorithm with unfortunate implications. So that either band could be used for backhaul, all AiMesh Nodes must be on the same channel on both bands, which maximizes Wi-Fi congestion in your network. Making matters worse, once AiMesh has selected a band for backhaul, it appears to stick with it. I did not observe any eero or Plume-style dynamic selection of backhaul band during testing. If the backhaul is on 5 GHz and so are all the clients, then 5 GHz gets all its airtime used while 2.4 GHz sits idle.

One thing AiMesh will do to attempt to avoid congestion is bandsteer clients from the backhaul band to the other. In my case, this meant steering from 5 GHz (where all clients initially connected) to 2.4 GHz. To be clear, this is a good move: you don’t want the traffic from your clients directly competing with its own backhaul for airtime. The problem is that ASUS still hasn’t quite figured out how to manage band steering without continually disconnecting clients. I had major issues with band steering and stability both times I tested the solo RT-AC3200, and I had the same issues this time around with AiMesh.

When I allowed AiMesh to use a single SSID for both 2.4 GHz and 5 GHz with Smart Connect enabled, it disconnected clients constantly – both under load (during testing) and while relatively idle.

Even looking at the network from Wi-Fi Analyzer on my Android phone was ridiculous – there are six beacons (SSID appearances) to see, one for each AP on each band (BSS). But at any given time, Wi-Fi Analyzer might only see one of them, might see all six, or any number in between. The SSID list – which should have been stable and unchanging – hopped around like crazy every time the viewport refreshed. Until ASUS figures out how to bandsteer clients without making the network unstable, readers would be wise to give each band a separate SSID, and distribute their devices manually to make best use of both.

AiMesh also decides whether each node will connect to another node, or directly to the main router. There’s no indication anywhere in the UI how nodes are connected. You just have a standard Wi-Fi “signal” icon next to each node that indicatges the connection quality.

In my case, I deliberately placed the second Node where it wouldn’t be able to get a decent connection directly to the router, so it was fairly obvious what was going on. Unfortunately, someone with a less intentional setup wouldn’t be able to determine what their topology looked like, short of resorting to an RF spectrum analyzer or similar tool.

How We Tested

AiMesh’s biggest appeal will be to people who already own a compatible ASUS router and are considering AiMesh to extend it. 22 different models currently support AiMesh and the list continues to grow, which can make the selection a daunting task. Since I already had an RT-AC1900P on hand, I took the easy way out and asked ASUS to send one of its RT-AC68U two-pack kits that would let me build a three-node AiMesh system.

My primary Wi-Fi test metric is application latency, where the application is a simulated web browsing experience. I simulate this experience using an open source tool called Netburn, which requests “webpages” frequently enough to match, but not exceed, a requested rate in Mbps.

Each “webpage” consists of sixteen separate 128K resources, fetched in parallel. The application latency is how long it takes from when the sixteen separate HTTP requests are sent out, to when all sixteen requests have finished coming back in. This adds up to 2 MB of data per page.

If this seems excessive, consider that Smallnetbuilder.com itself currently weighs in at 1.46 MB of data with 159 individual requests, and ESPN.com is 6.02 MB divided among a whopping 331 requests. In reality, an awful lot of the content you need to render each page you visit is fulfilled from cache that was populated the last time you visited it. This leads us to the relatively lightweight sixteen requests per page I use for testing. This is intended to be reasonably close to the number of resources your browser both can’t fulfill from cache, and actually needs prior to being able to render the page visually.

A webpage consisting of sixteen 128K files works out to be 2 megabytes of data, which in turn translates to 16 megabits. If we request these fetches frequently enough to move 1 Mbps of traffic, that works out to a new page download once every sixteen seconds. This, in turn, is a pretty reasonable simulation of an actual human sitting in front of a machine and messing around actively on the Web. Whether it’s clicking links or scrolling an infinite Facebook or Twitter feed, we’re at least in the right general ballpark. So a 1 Mbps netburn “browsing” run is neither a torture test nor a cakewalk; it’s a reasonable simulation of real-world activity.

All this explains my go-to benchmark, which is requesting a 1 Mbps stream of “web browsing” traffic from each STA, with enough randomly injected jitter to make sure we get a wide spectrum of the possible congestion effects. Injecting variation into the requests ensures multiple STAs might (or might not) request data at the same time, and either collide, or need to wait for the other to finish before making their own requests / receiving their own data. Once we’ve gathered all this data for a five minute run, we look at latency by percentile, from median (the most typical result) to 100th percentile (the worst result we got).

We can also request much higher rates of data – 4 Mbps, 8 Mbps, all the way up to 32 Mbps – to give us a better understanding of how, when, and why a system breaks down as increasing load is applied. These higher rates can be seen as roughly simulating a higher number of active users on the network, but truthfully veer much closer to “torture test” than an accurate simulation.

This all adds up to a lot of testing and data to analyze and absorb, and that’s for each AiMesh configuration! As I began testing, I found AiMesh behaved very differently depending on the number of nodes and whether they were connected using Wi-Fi or Ethernet backhaul. STA connection also heavily influenced performance. In general, STAs tended to connect to the same node, but the band they connected to made a difference. In the end, I tested over eight different configurations of nodes, backhaul and STA connection!

So I’ll be presenting the data boiled down into comparisons of different AiMesh configurations, with the common comparison point of the lone RT-AC1900P handling all four STAs. After all, we’re trying to determine whether AiMesh actually improves Wi-Fi performance.

The floorplan below shows the location of the (up to) three AiMesh nodes and four STAs used in all tests. The STAs are four identical Samsung Chromebooks running GalliumOS each equipped with a Linksys WUSB-6300 external wireless adapter. All traffic comes from the netburn server, which is connected via Ethernet to an RT-AC1900P router LAN port.

Floorplan showing AP (node) and STA locations

Standalone RT-AC1900P router

When set up by itself and only hit with a light amount (1 Mbps rate) of traffic, the RT-AC1900P did a reasonable job under the conditions it had to work with. The 3,500 sq ft, multiple floor test environment is frankly too much to ask a single router to handle; while nobody likes an extra second or more of lag, doing as well as it did is a credit to the RT-AC1900P.

In the solo tests of the RT-AC1900P, I allowed it to use band steering to place the STAs on 2.4 GHz or 5 GHz as it saw fit. It did a pretty good job; all STAs but STA B – the downstairs bedroom – are on 5 GHz. This results in a pretty long-range 5 GHz connection in STA A (the upstairs bedroom, at 40′ and four walls away), but I don’t fault its choice. The even longer range 2.4 GHz connection to STA A (about 70 feet, two walls, and one floor away) consumes a lot of airtime, so crowding B onto 2.4 GHz as well might not have worked any better.

Percentile latency (ms) – RT-AC1900P – 1 Mbps rate

The graph above plots application latency of each STA by percentile. Since we’re measuring latency (delay), lower numbers are better. So this means, for example, that STA C and D latency was below 1.25 seconds for 80% of the measurements made. The graph shows we’re looking at median page load times of > 500 ms even on our close range STAs C and D and > 1000 ms on all STAs by the 80th percentile. To me, this says that the RT-AC1900P is struggling with a relatively light load. Again, this is not a black mark against the router – this is far, far too wide a space to expect a single router to cover well with multiple, simultaneous active users.

The most useful data we get out of a simple, single-STA throughput test at each test site isn’t so much the number in Mbps itself; it’s an idea of how hard the router is struggling to reach each STA. Stations C and D – at about 30 feet and 20 feet and one interior wall away from the router – aren’t ideal sites for the highest possible throughput, but they’re well within the RT-AC1900P’s effective range.

Single Station throughput – Mbps

Station A, at 40 feet and four interior walls away, represents a significant challenge for a 5 GHz connection. The RT-AC1900P manages about a quarter the throughput to the better placed stations; many routers can’t handle a 5 GHz connection to that site at all. Finally, at close to seventy feet, an interior wall, and a floor at an oblique angle away, Station B is just plain ridiculous – even on the much longer-range, higher-penetration 2.4 GHz band. A station placed about ten feet closer in the same room wouldn’t actually be able to connect at all, due to the line of sight then needing to punch through a concrete foundation slab and several feet of earth.

All of this suffices to give us a good, solid baseline. The RT-AC1900P is a pretty impressive long range router that services this house about as well as any single router could. But that doesn’t mean “well enough to make everybody happy”. So let’s see if adding more routers in AiMesh can make things better.

Wi-Fi Backhaul

The obvious next step is to add one of our two RT-AC68U routers atop the Living Room TV console (Upstairs Node 2 in the floorplan), which puts it in a good, central spot that can reach both the router (for backhaul) and all of the STA locations. After that, we add the final RT-AC68U downstairs in the den (Downstairs Node 3 in the floorplan), directly underneath the Living Room TV router, and only one room over from STA A in the downstairs bedroom.

For these tests, I left band steering on. In theory, the AiMesh system should distribute the STAs and backhaul to best minimize congestion; this is the behavior we see in some dual-band mesh kits such as eero.

For all the following plots, we’re showing the mean of mean application latencies of 1, 4, 8, 16, 24, and 32 Mbps rates for each STA. So there is a lot of data condensed into these bars, from the lightest to heaviest network loads. The common element in each comparison is the RT-AC1900P by itself. Again, lower numbers (shorter bars) are better.

Mean application latency comparison – Wi-Fi backhaul

It shouldn’t come as a surprise that all STAs experience lower application latency with the addition of a single RT-AC68U in the living room, sitting right next to STA D. This is the central point in the test house, so we’re offering all STAs a shorter-range, higher-quality connection to the RT-AC68U than they had to the RT-AC1900P in the router closet.

What does come as a surprise is that adding our final RT-AC68U downstairs in the den increases application latency for STAs A and B, while providing only a slight latency reduction for STAs C and D. What’s going on there?

The answer, unfortunately, is poor bandsteering and naive use of spectrum by ASUS. In the significantly improved results with two AiMesh nodes, STA C is connected to the router on 5 GHz, STAs A and D are connected to the RT-AC68U in the living room on 5 GHz, and STA B is connected to the living room RT-AC68U on 2.4 GHz. This is a reasonable set of connections that makes good use of both bands, and offers three of the four stations closer-range links than they had with the RT-AC1900P alone.

When we add the second RT-AC68U downstairs, though, all four STAs now have a very close range connection suitable for 5 GHz available and all four, naively, are allowed to take it. STA A, C and D keep their same connections and only STA B changes connection to 5 GHz to the RT-AC68U in the downstairs den.

In this configuration, all STAs are directly competing for airtime both with one another and with their own backhaul. So despite our much improved individual link rates, our actual results are not only worse than they were with a single RT-AC68U, they’re worse than they were with the RT-AC1900P all by itself.

Ethernet Backhaul

Next, we’ll test our AiMesh system with Ethernet backhaul between the router and Node 2 in one case, and router and both nodes in another. The “3 nodes 2 Eth bkhl” bars in the plot below show Ethernet backhaul between the RT-AC68U in the living room and the RT-AC1900P in the router closet.

The “3 nodes Eth bkhl” bars show results with additional Ethernet backhaul between the RT-AC68U downstairs and the one upstairs. We should see tremendously improved results, here, since we no longer have to be concerned with STAs’ traffic competing for airtime with its own backhaul.

Mean application latency comparison – Ethernet backhaul

With just the upstairs RT-AC68U wired in (3 nodes 2 Eth bkhl in the chart), our results are worse than the solo RT-AC1900P for STA A and D, but better for STA B and STA C (only slightly). With both RT-AC68Us wired in (3 nodes Eth bkhl in the chart), STAs A, B, and D look good… but STA C is off-the-charts horrible. What’s going on here?

The answer is, again, poor spectrum management and band steering. With only the upstairs RT-AC68U hardwired (3 nodes 2 Eth bkhl ), STAs A, C, and D end up on 5 GHz directly to the RT-AC1900P through the entire run. STA B struggles to find a happy home, starting out connected on 5 GHz to the downstairs RT-AC68U. That’s a particularly horrible configuration because STA B congests directly with its own backhaul to the upstairs RT-AC68U, as well as with the traffic from STAs C and D.

Midway through the 8 Mbps test run, something causes STA B to move to the 2.4 GHz radio on the upstairs RT-AC68U. This is a noticeable improvement, and the latencies for all STAs were better the rest of the run – despite the rest of the run being the more demanding 16, 24, and 32 Mbps rates (this data isn’t shown). The net result is STA B latency still ends up lower than the reference RT-AC1900P only value.

When we add Ethernet backhaul to the downstairs RT-AC68U (3 nodes Eth bkhl), things improve… kinda. Although we’ve now completely eliminated the problem of STAs competing for airtime on their backhaul, ASUS’ funky, unpredictable bandsteering with its frequent outright disconnects has bitten us hard at STA C.

For the 1, 4, and 8 Mbps test runs, STA C is theoretically connected to the living room RT-AC68U on 5 GHz, but the test files (not shown) show it isn’t receiving much data. Then midway through the 8 Mbps test run, STA C reconnects to the upstairs RT-AC68U on 2.4 GHz and does much better. This time, however, the effect on overall latency is significant, increasing the mean of all results to over 52 seconds!

While it would be possible to give AiMesh a “mulligan” on this one and keep running the entire set of tests until nothing went wrong, this wouldn’t be realistic. My actual experience with AiMesh and band steering was represented very accurately by these tests. It was flakey, frequently disconnecting the STAs and generally being unpredictable and cranky. This experience matches up with an awful lot of user reports from around the web, so we left it as-is.

5 GHz STA Only

Since AiMesh’s bandsteering is unpredictable, unreliable, and frequently disconnects our STAs, it makes sense to see what we can get out of AiMesh with band steering disabled. So for the next comparisons, the 2.4 and 5 GHz radios each got different SSIDs and STAs were authenticated only for the 5 GHz SSID. We’re comparing two 3 node configurations, one with Wi-Fi backhaul for all nodes, the other with Ethernet for all nodes.

Mean application latency comparison – all STAs forced to 5 GHz

With band steering disabled, we finally got a predictable, solid set of results from our fully-wired three-node AiMesh system (3 nodes Eth bkhl No bndstr 5 GHz in the chart). All STAs see a significant improvement over and above the single RT-AC1900P router running by itself in the network closet, with STA A and B getting the largest improvement. In fact, this is the best set of results for all STAs for all tests I ran.

Unfortunately, Wi-Fi backhaul (3 nodes WiFi bkhl No bndstr 5 GHz in the chart) shows the effect of STAs and backhaul competing for airtime on the same radio. STA B’s mean-of-mean latency is the worst at 5.3 seconds because it connected to the downstairs node, giving STA B a two-hop connection back to the RT-AC1900P router.

Midway through the 4 Mbps test run STA B moved to the upstairs RT-AC68U 5 GHz radio. This worked out much better for STAs A, C, and D, since there was one fewer backhaul link clogging up the 5 GHz spectrum. Unfortunately it didn’t help STA B itself. With a much longer distance link to the upstairs RT-AC68U, its link rate dropped while STA A, C, and D all remained connected to the same upstairs RT-AC68U, with stronger signals and higher link rates.

2.4 GHz STA Only

I was pretty frustrated with AiMesh at this point. Its insistence on using the same channels on both radios on all three nodes, combined with its congestion-maximizing use of the same band for STAs and backhaul, kept me from getting anything like the throughput I would expect from a three node system.

Forcing the STAs to the 2.4 GHz band was my last hope for using a three-node AiMesh system with Wi-Fi backhaul. With the STAs all on 2.4 GHz, they should stop battling with their own backhaul.

Mean application latency comparison – all STAs forced to 2.4 GHz

But the last hopes for a workable three-node AiMesh system with Wi-Fi backhaul were dashed here. Although forcing all STAs to 2.4 GHz (3 nodes WiFi bkhaul No bndstr 2.4 GHz in the chart) did keep them from congesting with their own backhaul, the greater range and penetration of 2.4 GHz meant they maximally competed for bandwidth with each other instead.

All four STAs had higher latency when forced to connect to 2.4 GHz radios, but STA A and B were significantly worse. STA A, B and D all connected to the upstairs living room RT-AC68U. Only STA C, sitting right next to the same node, connected to the router. To make things worse, STA B changed to the downstairs RT-AC68U during the 16 Mbps rate test, moving from a one to two-hop connection.

Note the 5 GHz connection (3 nodes WiFi bkhl No bndstr 5 GHz in the chart) is the same data shown in the previous 5 GHz STA chart. This produced the worst latency of 5.3 seconds in this comparison.

Conclusion

I really like the overall premise of AiMesh – the idea that you should be able to add more routers to the router you already have and like, instead of needing to chuck it out and invest in a completely different mesh kit.

If you’ve currently got one AiMesh-capable ASUS router that you’re really happy with, adding a second in AiMesh mode instead of just using any old Wi-Fi extender isn’t the worst idea. The comparison below brings together the results from configurations that provided lower latency for all STAs than the the solo RT-AC1900P.

If you don’t have the option of Ethernet backhaul, you’d best stick to only adding only one AiMesh node (2 nodes WiFi bkhl). The results show lower mean application latency for all STAs with worst case latency of a bit over 850 ms for the most remote downstairs bedroom STA B.

Mean application latency comparison – best cases

If you have the option of Ethernet, my tests (3 nodes Eth bkhl No bndstr 5 GHz) show you can move up to two additional AiMesh nodes, but you’d best force your devices to all connect on 5 GHz. Doing all this and maybe with a little bit of good luck, I was able to keep all latencies for all STAs below 400 ms.

The bottom line is that the data show that AiMesh, at least in its current form, isn’t up to managing STAs and backhaul connections when both use the same pair of radios in each mesh node. And worse, AiMesh doesn’t use Ethernet backhaul effectively. So even if you don’t need the (Wi-Fi) mesh part of AiMesh and use Ethernet to connect all its nodes, it will give you worse performance than manually converting the routers to APs and configuring them yourself.

There are still some experiments I could have tried. For example, I could’ve tried dropping the 2.4 GHz transmit power to its absolute minimum and running the 2.4 GHz-only tests again. AiMesh is also clearly not really up to intelligently managing multiple-link backhaul; so I could also have tried pulling the downstairs RT-AC68U upstairs, and setting it up somewhere with a direct link to the RT-AC1900P router instead. I also could have introduced a tri-band router (or two) into the mix, to see if AiMesh could effectively use a second 5 GHz radio for dedicated backhaul.

But I didn’t do any of those things because the tests I did run, which have provided the most detailed examination of AiMesh performance you’ll find anywhere, show there are much better, less frustrating and less expensive options for Wi-Fi mesh systems.

Testing I’ve done for another publication has shown Orbi, eero, and Plume “Superpods” were able to handle the same four STAs using Wi-Fi backhaul (which is why you buy a mesh Wi-Fi system in the first place) and produce comparable mean application latencies. While these compeing system’s ain’t cheap, neither is the AiMesh configuration I tested. But they have the advantage over AiMesh of not requiring Ethernet connection to provide as good or better results.

Platform
Configuration
Price

ASUS AiMesh

– RT-AC1900P (x1)
$135
– RT-AC68U (x2)
$280
NETGEAR Orbi
RBK53 One router, two satellites
$520
eero
eero + two Beacons
$398
Plume
Superpod (x4)
$460

Table 1: Wi-Fi mesh system pricing (click links for latest prices)

And if your spouse is a believer that good Wi-Fi should not clash with the home decor, then AiMesh is likely to lose that battle.

Which do you think will have higher SAF?

So again, If you don’t already own an ASUS router and you’re in the market for a multiple access point system, there are frankly better options. If you have or plan to deploy wired Ethernet backhaul to your access points, purpose-built wired access points such as Ubiquiti UAP-AC-Lite, TP-Link EAP-225v3 or other APs reviewed in the 2×2 AC Access Point Roundup series are both less expensive and higher performance than AiMesh routers.

If you can’t or don’t want to use Ethernet backhaul and just want mesh, mesh Wi-Fi systems such as eero with a pair of Beacons still cost at least a little less than most AiMesh options, and tend to be more stable, easier to live with, and higher in Spouse Acceptance Factor.

Discuss this in the Forums