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 Features

802.11 channel map - Ruckus Wireless

Image credit: Ruckus Wireless

Introduction

Updated 10/10/18: Link to retest article. Noted Pal 160 MHz uplink bug
Some tests were rerun due to problems found in the test methods. See the retest article.

Support for 160 MHz channel bandwidth in 5 GHz is included in the 802.11ac standard. Its raison d'etre has been to enable mobile clients, which typically support one or two streams, to double their link rates to achieve higher bandwidth. So, for example, a single stream AC device that achieves only a 433 Mbps maximum link rate could double up to 867 Mbps and a two-stream client that maxes out at 867 Mbps count achieve a four stream equivalent maximum of 1.7 Gbps.

The catch is 160 MHz eats up eight adjacent 20 MHz wide channels. As the channel map above shows, this isn't possible in the U.S. without using UNII-2 and 2e DFS channels. Router makers have generally avoided the extra complexity of designing their products to support DFS and the extra cost of the separate FCC certification required.

There is also an alternative of "80+80" mode, which allows a gap between two four-channel groups. This avoids using DFS channels, but uses all eight 5 GHz channels available to U.S. users. (Yes, there is channel 165, but that's helpful only if you're running 20 MHz 5 GHz channels).

Fortunately for those struggling with overcrowded networks, support for 160 MHz channels has not caught fire in 802.11ac. Only a handful of designs have opted to support 160 MHz or 80+80 bandwidth, usually more as a marketing ploy to inflate router class numbers, as Linksys did with its Marvell-based "AC3200" WRT3200ACM . NETGEAR's R7800 and R9000 and Synology' RT2600ac are the only ones that come to mind to support 160 MHz bandwidth.

Supporting 80+80 mode complicates (and increases cost) of radio design in wireless devices. So most smartphone and mobile device makers have opted to not support either 160 or 80+80 MHz bandwidth mode. Since smartphone makers are notoriously secretive about Wi-Fi specs, I have no idea if there are any 160 or 80+80 devices out there. I'm told the only 11ac device that supports 160 MHz mode is Intel's Wireless-AC 9260 M.2 card for notebooks. As you'll see in a bit, I confirmed that it does indeed support contiguous 160 MHz.

160 MHz Channels Rising

So 160 MHz is unlikely to have had much effect on your home Wi-Fi network's performance up to now. But that could change with 11ax. I pointed out in 5 Things To Know Before You Buy A Draft 11ax Router that ASUS' "AX6000" RT-AX88U is counting on 160 MHz channels, 1024 QAM modulation and four-streams to reach the specified 4804 Mbps maximum 5 GHz link rate.

ASUS' "AX11000" GT-AX11000 counts on the same combination, plus the addition of a second 5 GHz radio to push up its link rate. And when you see the first eight stream (all in 5 GHz, not 4 in 2.4 GHz + 4 in 5 GHz like NETGEAR is using to position its AX routers) routers announced, they too will use 160 MHz channel bandwidth as part of the requirements to reach top link rate.

All that means is that it's likely you'll see all first draft 11ax routers support 20/40/80/160 MHz bandwidth modes and DFS. And it's also likely that some of those buyers may also pick up an Intel AC 9260 to get some benefit, aside from bragging rights, from that premature purchase. Put those two things together and the probability of a 160 MHz 5 GHz network parked next door is headed upward. So does this spell the end of your 5 GHz network performance?

Let's Test

So that I don't go all Chicken Little about 160 MHz and the death of Wi-Fi, I ran some experiments to get some data. I set up two 5 GHz 802.11ac networks, one using an ASUS RT-AC86U to provide a WLAN with 80 MHz wide channels and the other with a NETGEAR R7800 with HT160 mode enabled (found in the Advanced Wireless settings). For those keeping score, the ASUS is Broadcom-based; the NETGEAR uses a Qualcomm platform.

  ASUS RT-AC86U NETGEAR R7800
CPU Broadcom BCM4906
dual core ARM v8 Cortex A53 @ 1.8 GHz
Qualcomm dual-core IPQ8065 Internet Processor @ 1.7 GHz
Switch In BCM4906 Qualcomm Atheros QCA8337
RAM 512 MB 512 MB
Flash 256 MB 128 MB
2.4 GHz Radio - Broadcom BCM4365E 3x3 11abgn-ac SoC
- 2.4 GHz RF front end (x3)
- QCA9984 4x4 MU-MIMO 802.11ac radio
- Skyworks SE2623L 2.4 GHz power amp (x4)
5 GHz radio - Broadcom BCM4366E 4x4 11abgn-ac SoC
- 5 GHz RF front end (x4)
- QCA9984 4x4 MU-MIMO 802.11ac radio
- RFMD RFPA5542 5 GHz PA module (x4)
Table 1: Router key components

I put each router in an octoScope octoBox so that I had the option of "separating" the networks by closing the doors and adjusting the attenuators. But I ended up running all the tests I'll be presenting with the doors open.

80 / 160 MHz bandwidth sharing test configuration

80 / 160 MHz bandwidth sharing test configuration

For most of the tests, I used two 5 GHz octoScope Pal devices, which are based on Qualcomm chipsets. Although the Pal supports up to four streams, I configured each to act as a 2x2 802.11ac device (STA).

I used iperf3 running TCP/IP traffic, 2048 kB window size with four simultaneous streams, each set to a 100 Mbps offered load to each STA. I limited traffic to this level so that I wasn't totally saturating the link and because I was limited to using a single Gigabit Ethernet connection to the test console/traffic generator.

Test 1: Maximum Throughput - 160 vs. 80

Before we get to pitting networks against each other, let's first see if trying to use 160 MHz bandwidth is worth it at all. For this test, I used the setup above, but used only one network and Pal STA and removed the bandwidth restrictions on the iperf3 streams.

Maximum throughput - 80 vs. 160 MHz channels - downlink

Maximum throughput - 80 vs. 160 MHz channels - downlink
160 MHz AVG = 943 Mbps 80 MHz AVG = 682 Mbps

For downlink, using 160 MHz bandwidth results in an almost 40% throughput gain. (Since the link is running right at the ~940 Mbps limit for TCP/IP, this is likely contrained by the Gigabit Ethernet link.) But this falls to only about 4% gain for uplink.

Maximum throughput - 80 vs. 160 MHz channels - uplink

Maximum throughput - 80 vs. 160 MHz channels - uplink
160 MHz AVG = 707 Mbps 80 MHz AVG = 677 Mbps

The reason is something I frequently see when trying to achieve maximum throughput using techniques that try to push the bandwidth envelope. Pal telemetry showed the correct 866 Mbps link rate for both transmit and receive when using 80 MHz bandwidth. But for 160 MHz bandwidth, only the receive rate achieved the desired 1733 Mbps; transmit rate remained at 866 Mbps.

I can't explain why this occurs. But the effect was consistent across multiple tests.

Updated 10/10/18: The low link rate is due to a Pal firmware bug. See the retest article for details and new data.

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