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.