Image credit: Ruckus Wireless
Introduction
Updated 10/10/18: Link to retest article. Noted Pal 160 MHz uplink bug
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 3×3 11abgn-ac SoC – 2.4 GHz RF front end (x3) |
– QCA9984 4×4 MU-MIMO 802.11ac radio – Skyworks SE2623L 2.4 GHz power amp (x4) |
| 5 GHz radio | – Broadcom BCM4366E 4×4 11abgn-ac SoC – 5 GHz RF front end (x4) |
– QCA9984 4×4 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
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 2×2 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
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
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.
Test 2: 80 MHz – Both Channel 36
The first test established a baseline with both routers set to 80 MHz bandwidth and set to Channel 36 to see how two normal neighboring AC networks play together. In all plots, AP1 is the ASUS and AP2 the NETGEAR.
Two 80 MHz networks – Both Ch 36 – Downlink
AP1 AVG= 254 Mbps AP2 AVG = 348 Mbps
Downlink (AP to STA) shows the ASUS network averaging slightly under 20% lower throughput vs. the NETGEAR for the run. For uplink, the difference in average throughput is around 2x higher than downlink, just shy of 40%
Conclusion: Even for two AC networks, bandwidth may not be shared equally.
Two 80 MHz networks – Both Ch 36 – Uplink
AP1 AVG= 244 Mbps AP2 AVG = 398 Mbps
Test 3: 80 MHz – AP1 to Ch 40
For the next test, I just changed the ASUS’ channel selector from 36 to 40 to gauge the effect (if any) of changing the primary channel. Note that 80 MHz wide channels were still set for borh routers.
Two 80 MHz networks – AP1 Ch 40 – Downlink
The downlink plot clearly shows something different afoot, with ASUS’ throughput falling to zero about a minute into the run, then everything stopping around 75 seconds.
Pal telemetry shows the Pal associated with the ASUS started scanning for a new connection around 70 seconds and never successfully reassociated. Meanwhile the NETGEAR-connected Pal remained associated. The run stopped when the ASUS’ iperf3 connection terminated. I ran this test a few times, with similar results.
Uplink behavior was better, but the ASUS network’s average throughput was again lower than the NETGEAR’s (~ 35%). So why the downlink wonkiness?
Two 80 MHz networks – AP1 Ch 40 – Uplink
AP1 AVG= 259 Mbps AP2 AVG = 397 Mbps
One of the "features" of at least 802.11ac consumer routers and Wi-Fi systems is how they mislead users into thinking there are more non-interfering channels than there really are.
Contrary to what your router settings may show, there are not really eight (9 if you count Channel 165) 80 MHz wide channels available in the 5 GHz band (I’m using U.S. rules for this example). Although the channels themselves do not overlap, 80 MHz channel bandwidth requires using four of the (20 MHz wide) channels you see in your router’s 5 GHz channel selector, for each channel you select.
So there are really only two 5 GHz "channels" where bits flying through the air using one don’t collide with those using the other. The channel use diagram below shows this more clearly, showing only one channel (42) in the 5 GHz "low" UNII-1 band and one (155) in the UNII-3 "high" band.
Image credit: Ruckus Wireless
The diagram also shows why adding DFS support, i.e. access to UNII-2 and UNII-2e frequencies, is so valuable. It brings four more truly non-overlapping 80 MHz wide channels into play (channels 58, 106, 122 and 138).
So when you set a 5 GHz channel on a consumer router, you’re really just setting the primary operating channel. This channel is where beacons and other channel management frames are sent. The primary channel also determines how an AP adjusts its channel width when it detects a neighboring network using a different primary channel that falls in its extension channels.
This channel width adjustment is supposed to operate on a frame-by-frame basis to ensure the best use of airtime. This Revolution WiFi post is the best explanation I can find of how 11ac’s channel use scheme works, and you may still come away confused.
All this is a long way round to attempt to explain why the ASUS router had such a difficult time when I just changed its primary channel. Although both routers saw another network operating on a different primary channel than their own, the ASUS appears to have been more affected than the NETGEAR.
Conclusion: Normal (80 MHz wide channels) neighboring 11ac networks can significantly affect each other.
Test 4: 80 & 160 MHz Networks – Both Ch 36
With the 80 MHz channel width tests out of the way, I next enabled the NETGEAR’s HT160 mode and set the ASUS channel back to 36. The Pal connected to the NETGEAR was also set to use 160 MHz wide channels.
80 MHz & 160 MHz networks – Both Ch 36 – Downlink
AP1 AVG= 195 Mbps AP2 AVG = 344 Mbps
Well, this is encouraging. The two networks behave similarly to when both were using 80 MHz wide channels. The 80 MHz channel network running on the ASUS still had lower throughput than the 160 MHz channel network running on the NETGEAR. But the difference is again around 20% for downlink and 40% for uplink.
Conclusion: 160 MHz wide channels appear to have the same effect on a neighboring network using 80 MHz channels as a neighboring network using 80 MHz wide channels.
80 MHz & 160 MHz networks – Both Ch 36 – Uplink
AP1 AVG= 252 Mbps AP2 AVG = 400 Mbps
Test 5: 80 & 160 MHz Networks – 80 MHz to Ch 40
This test is essentially the same as Test 3, but with the NETGEAR set to 160 MHz wide channel.
80 MHz & 160 MHz networks – AP1 Ch 40 – Downlink
The results are eerily similar to Test 3, but more pronounced. The ASUS network using 80 MHz wide channels is clearly struggling throughout the test and again starts scanning for a new network after its throughput essentially drops to zero for around 10 seconds. Pal telemetry shows the Pal STA does reassociate a few seconds later, but that’s too much of an interruption for iperf3, which doesn’t resume traffic.
The uplink test shows much more even throughput sharing for much of the run than Test 3 (~5% difference). The test once again ends early, but only slightly. Pal telemetry showed no problem with association, but something caused iperf3 to disconnect a bit early.
Conclusion: The effect of a neighboring 160 MHz wide channel network appears to be no worse than an 80 MHz wide channel network.
80 MHz & 160 MHz networks – AP1 Ch 40 – Uplink
AP1 AVG= 333 Mbps AP2 AVG = 313 Mbps
Test 6: 80 & 160 MHz Networks, Intel AC 9260 STA – Both Ch 36
As noted earlier, pickin’s are very slim if you’re looking for 802.11ac devices that support 160 MHz wide channels. Since it’s possible there is some optimization that could occur between the Qualcomm-based NETGEAR R7800 and Qualcomm-based octoScope Pal device, I decided to run the same tests using an Intel AC 9260.
I wasn’t able to get the card to be recognized in a Lenovo M600 Tiny Desktop running Windows 10. But was able to get it running in a Dell XPS13 9350 running Windows 10. The XPS13 was located a few feet from both routers and ran an iperf3 server endpoint. The Intel driver version used was 20.80.1.1.
I jumped right to testing the AC 9260 in 160 MHz bandwidth mode, with both routers set to channel 36. As a reminder, AP1 is the network with an ASUS RT-AC86U and Pal 5 set to 80 MHz channel bandwidth and AP2 is the NETGEAR R7800, now with an Intel AC 9260 STA.
The first test is the same as Test 4, except it uses the Intel STA instead of an octoScope Pal as the 160 MHz channel bandwidth STA.
80 (Pal) & 160 (Intel) MHz networks – Both Ch 36 – Downlink
AP1 AVG= 400 Mbps AP2 AVG = 162 Mbps
I didn’t expect to see the ASUS-based 80 MHz channel network outdo the NETGEAR/Intel WLAN, but that’s what happened. I showing the better of two runs made. In the other run, the two networks wrassled even more at the start, with the 80 MHz network again coming out on top. The 160 MHz channel network had 60% lower average throughput than the standard 80 MHz wide network.
Uplink results were even more surprising. Pal telemetry for the 80 MHz network showed no scanning or breaks in association. But something happened to take down the iperf3 stream, which eventually killed the test.
Conclusion: The Intel AC 9260 did not fare as well in this test as the Qualcomm-based Pal. Something is very wrong on uplink.
80 (Pal) & 160 (Intel) MHz networks – Both Ch 36 – Uplink
Test 7: 80 & 160 MHz Networks, Intel AC 9260 STA – 80 MHz to Ch 40
The next tests repeat the Test 5 setup, but again with the Intel STA.
80 (Pal) & 160 (Intel) MHz networks – AP1 Ch 40 – Downlink
AP1 AVG= 400 Mbps AP2 AVG = 95 Mbps
Once again, the standard 11ac 80 MHz channel network cruised along at its 400 Mbps top throttled throughput, while the 160 MHz network hugged the 100 Mbps line, coming in with an average throughput almost 80% lower.
The uplink test ran a little longer than when both networks used the same primary channel (36).
Conclusion: Once again, something seems seriously wrong with the way the Intel AC 9260 STA and NETGEAR R7800 interact.
80 (Pal) & 160 (Intel) MHz networks – AP1 Ch 40 – Uplink
Test 8: Intel alone, 160 MHz channel
I ran just the Intel AC 9260 and NETGEAR R7800 in 160 MHz channel mode to see if that provided any clues to the Test 6 and 7 behavior. Channel was set to 36, and iperf3 was set to use four TCP/IP streams with no bandwidth caps. Here’s the result of four downlink test runs…
Intel AC 9260 – 160 MHz B/W – Downlink
Run1 AVG= 402 Mbps Run2 AVG = 941 Mbps Run3 AVG = 941 Mbps Run4 AVG = 926 Mbps
…and four uplink. All these tests were run in a 15 minute period with no other active in-range 5 GHz networks.
Two of the four downlink runs ran at an average 1 Gbps Ethernet link rate of 941 Mbps, one stumbled a bit near the start and one didn’t do well at all.
Intel AC 9260 – 160 MHz B/W – Uplink
Run1 AVG= 382 Mbps Run2 AVG = 214 Mbps Run3 AVG = 610 Mbps Run4 AVG = 605 Mbps
For uplink, we again see two of the four runs do ok, but the other two, not so much.
While this was an interesting and worthwhile exercise, it provides no clues to why the 160 MHz network using the Intel AC 9260 produced significantly lower throughput in the 80/160 neighboring network tests.
Closing Thoughts
It’s easy to get lost in the data. So here’s a handy table of the results and conclusions for each test.
| Test | Downlink Throughput | Uplink Throughput | Conclusion |
|---|---|---|---|
| Test 1: Maximum Throughput – 160 vs. 80 | – 160 MHz avg. = 943 Mbps – 80 MHz avg. = 682 Mbps |
– 160 MHz avg. = 707 Mbps – 80 MHz avg. = 677 Mbps |
Steady throughput, both directions, both networks |
| Test 2: 80 MHz – Both Channel 36 | – ~20% avg. throughput difference – AP1 avg. = 254 Mbps – AP2 avg. = 348 Mbps |
– ~40% avg. throughput difference – AP1 avg. = 244 Mbps – AP2 avg. = 398 Mbps |
Even for two AC networks, bandwidth may not be shared equally. |
| Test 3: 80 MHz – AP1 to Ch 40 | – Disconnect on one network during test | – AP1 avg. = 259 Mbps – AP2 avg. = 397 Mbps |
Normal (80 MHz wide channels) neighboring 11ac networks can significantly affect each other. |
| Test 4: 80 & 160 MHz Networks – Both Ch 36 | – AP1 avg. = 195 Mbps – AP2 avg. = 344 Mbps |
– AP1 avg. = 252 Mbps – AP2 avg. = 400 Mbps |
160 MHz wide channels appear to have the same effect on a neighboring network using 80 MHz channels as a neighboring network using 80 MHz wide channels. |
| Test 5: 80 & 160 MHz Networks – 80 MHz to Ch 40 | – Disconnect on one network during test | – AP1 avg. = 333 Mbps – AP2 avg. = 313 Mbps |
The effect of a neighboring 160 MHz wide channel network appears to be no worse than an 80 MHz wide channel network. |
| Test 6: 80 & 160 MHz Networks, Intel AC 9260 STA – Both Ch 36 |
– AP1 avg.= 400 Mbps – AP2 avg. = 162 Mbps |
– Disconnect on one network during test | The Intel AC 9260 did not fare as well in this test as the Qualcomm-based Pal. Something is very wrong on uplink. |
| Test 7: 80 & 160 MHz Networks, Intel AC 9260 STA – 80 MHz to Ch 40 |
– AP1 avg. = 400 Mbps – AP2 avg. = 95 Mbps |
– Disconnect on one network during test | Once again, something seems seriously wrong with the way the Intel AC 9260 STA and NETGEAR R7800 interact. |
| Test 8: Intel alone, 160 MHz channel | – Run1 avg. = 402 Mbps – Run2 avg. = 941 Mbps – Run3 avg. = 941 Mbps – Run4 avg. = 926 Mbps |
– Run1 avg. = 382 Mbps – Run2 avg. = 214 Mbps – Run3 avg. = 610 Mbps – Run4 avg. = 605 Mbps |
– Inconsistent throughput run-to-run. – No indication of behavior seen in Tests 6 & 7 |
Table 2: Test conclusion summary
My data set is admittedly small. But I tend to think that if I can’t see an advertised behavior in controlled conditions and with careful testing, then the chance of a typical user seeing the behavior is low.
So my basic takeaway is that an 802.11ac network using 160 MHz channel bandwidth parked next door could have an adverse effect on your wireless network. But no more or less than a regular 11ac network using 80 MHz channels.
And if that neighbor is using an Intel AC 9260—and they likely are since it’s the only 11ac device that supports 160 MHz channels—your network might be more likely to make them unhappy than vice versa.
Of course, all this will probably change when we see 11ax networks using 160 MHz channels. So I’ll get to repeat this exercise then.