Image credit: Ruckus Wireless
After 160 MHz Wi-Fi Channels: Friend or Foe? posted, I heard indirectly from some folks in the Wi-Fi biz that some of the results were not as they would expect. The most notable was the 867 Mbps uplink rate for a 160 MHz wide channel. I noted this in the article, but didn’t know the cause.
Well, it turns out there was a bug in the octoScope Pal firmware that caused it to function at 80 MHz bandwidth on uplink only, even when it was set to 160 MHz mode. So I installed a bug-fixed version and reran the maximum throughput tests. Here is the original downlink plot…
Maximum throughput – 80 vs. 160 MHz channels – downlink
160 MHz AVG = 943 Mbps 80 MHz AVG = 682 Mbps
… which looks a lot like the retested results. I’d expect this, since downlink (Pal receive) link rate alternated between 1560 and 1733 Mbps.
Maximum throughput – 80 vs. 160 MHz channels – downlink – RETEST
160 MHz AVG = 943 Mbps 80 MHz AVG = 622 Mbps
Uplink was different, as we should expect. Here’s the original plot, showing just about equal results for 80 and 160 MHz channel widths…
Maximum throughput – 80 vs. 160 MHz channels – uplink
160 MHz AVG = 707 Mbps 80 MHz AVG = 677 Mbps
…and here is the retest, which shows more than 30% higher throughput using a 160 MHz channel.
Maximum throughput – 80 vs. 160 MHz channels – uplink – RETEST
160 MHz AVG = 937 Mbps 80 MHz AVG = 709 Mbps
So yes, you should see higher throughput in both directions when using 160 MHz channels. I apologize for the error.
The other main chatter I heard was about the poor results using the Intel AC 9260 as STA. The comments implied there is incompatibility between the Intel AC 9260 and Qualcomm QCA9984 5 GHz radio used in the NETGEAR R7800. To my knowledge, this is Qualcomm’s only AC device that supports 160 MHz bandwidth mode.
I also found that rebooting the NETGEAR R7800 could improve link rates and smooth out throughput when things looked hinky operating in 160 MHz bandwidth mode.
So I went back and reran throughput tests between the Intel STA and NETGEAR router. I ran four tests in each direction with HT160 mode enabled in the NETGEAR and with it disabled. I used the same (latest) driver and notebook as before (Dell XPS13 9350 running Windows 10, 184.108.40.206 driver). Here’s the downlink retest…
Intel AC 9260 – 160 MHz B/W – Downlink – RETEST
Run1 AVG=847 Mbps Run2 AVG=774 Mbps Run3 AVG=848 Mbps Run4 AVG=944 Mbps
and here’s the original test. There’s obviously still some instability.
Intel AC 9260 – 160 MHz B/W – Downlink
Run1 AVG= 402 Mbps Run2 AVG = 941 Mbps Run3 AVG = 941 Mbps Run4 AVG = 926 Mbps
Here is the uplink retest…
Intel AC 9260 – 160 MHz B/W – Uplink – RETEST
Run1 AVG=336 Mbps Run2 AVG=672 Mbps Run3 AVG=263 Mbps Run4 AVG=21 Mbps
..and the original.
Intel AC 9260 – 160 MHz B/W – Uplink
Run1 AVG= 382 Mbps Run2 AVG = 214 Mbps Run3 AVG = 610 Mbps Run4 AVG = 605 Mbps
These results look worse than the original run, since only one of the four runs completed the shorter 65 second test. But on the other hand, maximum throughput was much higher, around 800 Mbps vs. 600 Mbps in the original run.
I attribute this to the fact that I verified that the R7800 was behaving itself in 160 MHz mode by checking throughput first with the octoScope Pal. So there does appear to be some incompatibility between Intel and Qualcomm when using a 160 MHz channel.
Intel – 80 MHz Channel
Since Intel and Qualcomm didn’t pair nicely in 160 MHz, I decided to see how they worked with a normal 80 MHz AC channel. Turns out, not so well. Here’s a plot of four downlink runs with HT160 mode disabled on the R7800 (its default mode)…
Intel AC 9260 – 80 MHz B/W – Downlink
Run1 AVG=575 Mbps Run2 AVG=522 Mbps Run3 AVG=540 Mbps Run4 AVG=557 Mbps
… and uplink.
Intel AC 9260 – 80 MHz B/W – Uplink
Run1 AVG=59 Mbps Run2 AVG=139 Mbps Run3 AVG=369 Mbps Run4 AVG=165 Mbps
I suspect this poor uplink behavior is related to the difference in the way Intel and Qualcomm support 160 MHz bandwidth. More on this later.
Retest 4: 80 & 160 MHz Networks – Both Ch 36
So what about the effect of a neighboring network running 160 MHz channels on a normal AC network using 80 MHz running uplink? I retested that too. I made sure to check that the R7800’s 160 MHz link rates were correct and the throughput was nice and smooth before running these tests.
Here’s the retested downlink result. It shows both networks equally sharing bandwidth, i.e. neither is affecting the other.
80 MHz & 160 MHz networks – Both Ch 36 – Downlink – RETEST
AP1 AVG= 389 Mbps AP2 AVG = 387 Mbps
Let’s pull in the results from Test 2 of the original article for comparison, which shows the NETGEAR network (AP2) with a bit under 40% higher average throughput.
Two 80 MHz networks – Both Ch 36 – Downlink
AP1 AVG= 254 Mbps AP2 AVG = 348 Mbps
The same comparison for uplink shows about 30% higher throughput for the 160 MHz channel network
80 MHz & 160 MHz networks – Both Ch 36 – Uplink – RETEST
AP1 AVG= 303 Mbps AP2 AVG = 399 Mbps
And now uplink for two 80 MHz channel networks.
Two 80 MHz networks – Both Ch 36 – Uplink
AP1 AVG= 244 Mbps AP2 AVG = 398 Mbps
My takeaway is there are no new insights here. A WLAN using 160 MHz channels is as likely to affect you as a regular ol’ AC network using 80 MHz channels.
Retest 5: 80 & 160 MHz Networks – 80 MHz to Ch 40
Finally, I also rechecked what happens when the neighboring 80 MHz channel network moves its primary channel to 40. Here’s downlink…
80 MHz & 160 MHz networks – AP1 Ch 40 – Downlink – RETEST
AP1 AVG= 389 Mbps AP2 AVG = 387 Mbps
80 MHz & 160 MHz networks – AP1 Ch 40 – Uplink – RETEST
AP1 AVG= 389 Mbps AP2 AVG = 387 Mbps
These plots show more stable throughput than the previous tests, which I attribute more to making sure the R7800 was operating properly than any 80 / 160 MHz channel interactions.
My bottom line after retesting is still the same: I don’t see a properly functioning wireless network using 160 MHz channels having any more or less affect than a WLAN using 80 MHz wide channels. But that properly functioning is the potential gotcha.
The significantly different (and poorer) results using the Intel AC 9260 STA with the Qualcomm-based R7800 are a cause for concern. And they could forebode an upcoming battle in 11ax.
The 802.11-2016 standard specifies two ways to achieve a 160 MHz channel; eight contiguous channels (aka "160") or two groups of four contiguous channels (aka 80+80). I haven’t seen the draft 11ax spec, but I assume it carries this forward.
Supporting 80+80 basically requires two radios because they need to be tuned to different channels spaced further apart than 160 MHz, while 160 support requires only one radio, but capable of extra wide bandwidth. I can see how an 80+80 STA can also connect to a "true", i.e. contiguous 160 MHz AP and link at 160 MHz channel rates.. But I can’t figure out how a "true" 160 MHz STA can connect to an AP that supports only 80+80 and achieve a 160 MHz channel link.
In fact, the Intel AC 9260 connected at only at 867 Mbps when I set the R7800’s primary channel to 149 with HT160 mode enabled, which resulted in an 80+80 channel assignment. (The NETGEAR advanced status screen showed Channels 36+40+44+48+149(p)+153+157+161.)
Even though the AC 9260 showed 1733 Mbps link rate connected to the NETGEAR when the NETGEAR’s primary channel was set to 36 (resulting in a contiguous 160 MHz channel using DFS channels, i.e. 36(p)+40+44+48+52+56+60+64, its poor uplink behavior—in both 80 and 160 MHz channel widths—says something isn’t up to par.
As I said, we’ll see how this all shakes out when I get my hands on the first draft 11ax routers, which is likely to be the ASUS RT-AX88U that has popped up for pre-order at many etailers.