Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Wireless Reviews

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

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

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

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.

More Wireless

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

Stubby is an application that acts as a local DNS Privacy stub resolver using DNS-over-TLS. Stubby encrypts DNS queries sent from a client machine to ...
HelloI have RT-AC87U Router with latest Merlin firmware and my network have access to address starts from 192.168.10.1 to 192.168.11.254. My IP of rou...
As you already noticed entware-ng (http://pkg.entware.net/binaries/mipsel) doesn't get updated anymore.The repo on github is archived (read-only) and ...
Hi,I have RT-AC86U on latest merlin FW 384.7. At the same time i have 2 x 1Gpbs connection from 2 diff ISPs.I have configured load-balancing ratio of ...
Any ideas on how to get overclocking working on RT-AC68U running 384.7? I am using JFFS scripts to set clkfreq to 1200,666. This is working (verified ...

Don't Miss These

  • 1
  • 2
  • 3