What's new

160 MHz Wi-Fi Channels: Friend or Foe?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

thiggins

Mr. Easy
Staff member
80_and_160mhz_channels.jpg
160 MHz channel bandwidth is an essential feature of 802.11ax. We take a look at whether it means trouble for your 11ac network.

Read on SmallNetBuilder
 
Last edited:
Interesting article. What driver version did you use with the Intel? Versions before 20.70 have a few compatibility issues, don't know if they apply to 160 MHz channels or to 802.11ax STAs however.
 
20.80.1.1 64 bit. I updated the article.

Thanks. That's the latest, so this rules out driver issues (unless it's a different issue Intel hasn't addressed yet).
 
Nice article...

In test cases (2) and (3), simulating the adjacent network, how much additional attenuation are you adding for the simulated neighbor AP?
 
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.

Wondering if this is an artifact of the QCA chip firmware in the PAL regarding RTS/CTS behavior on the uplink when in client STA mode?
 
Nice article...

In test cases (2) and (3), simulating the adjacent network, how much additional attenuation are you adding for the simulated neighbor AP?
The neighboring network isn't simulated. It's a real router and STA.

The two APs are fairly close, in adjacent octoBox chambers, but with doors open.
 
Wondering if this is an artifact of the QCA chip firmware in the PAL regarding RTS/CTS behavior on the uplink when in client STA mode?
Could be possible. I checked with octoScope before posting the review. Have not heard anything back.

I've seen this uplink/downlink difference with 80 MHz bandwidth devices too. Usually four stream products.
 
While not exactly on point here, I see this notion of a higher speed or rather greater data moved at a given moment is not a bad idea for WiFi bridges or items like Netgear Orbi where the two modules talk to each other. The devices (computers etc.) do not directly use the 160 bandwidth.

end user device <---ac--
> router<------ax----->router<---ac--->end user device.
 
Great testing and analysis, as usual. It will be interesting to see how 802.11ac 160 MHz performance compares with draft-11ax, once draft-11ax STAs become available.
 
Interesting that some of those runs were so erratic.

At least with large file transfers I was getting consistent/stable transfers of 104-114 MB/s downlink depending on the location in my home on my R7800 with HT160 (9260ac in a Dell 7577) using a ReadyNAS 524X as the source for downloads.

As for the Intel driver, I think before the .50 or .60 series drivers can’t recall which but there would be occasional dropouts on 160Mhz. Then everything was fine till the latest R7800 .58 firmware that pretty much made 5Ghz useless.
 
Last edited:
Interesting that some of those runs were so erratic.

At least with large file transfers I was getting consistent/stable transfers of 104-114 MB/s downlink depending on the location in my home on my R7800 with HT160 (9260ac in a Dell 7577) using a ReadyNAS 524X as the source for downloads.

As for the Intel driver, I think before the .50 or .60 series drivers can’t recall which but there would be occasional dropouts on 160Mhz. Then everything was fine till the latest R7800 .58 firmware that pretty much made 5Ghz useless.
So were the stable transfers done with R7800 .58 firmware or earlier? I used version 1.0.2.58 (latest).
 
The latest 1.0.2.58 firmware is causing major stability isssues with the 9260ac, intermeittent disconnects. 2.4 GHz is fine. My 160Mhz testing was done on firmwares earlier than .58.

Looking back at some of my earlier posts on other threads, seems I was testing the 9260ac since Feb, and I usually am on the latest router firmware/wireless drivers, so all the firmwares since that period were fine except for this .58 update. There was an earlier issue where on HT160 the 9260ac would disconnect but that was an Intel driver issue fixed somewhere in the 20.50.X.X/20.60.XX series drivers.

There were a few people complaining on Netgear’s forums regarding issues with latest firmware update in regards to 5Ghz.

Some of my initial testing mentioned here:
https://www.snbforums.com/threads/review-of-intel-wireless-ac-9260-9560.44622/#post-381423
 
Last edited:
The neighboring network isn't simulated. It's a real router and STA.

The two APs are fairly close, in adjacent octoBox chambers, but with doors open.

You know - MESH likely is going to land on the same channel across the AP's...

This is the...

download.jpg


with regards to the testing with neighboring BSS/ESS sets - as the popular Mesh things are likely going to share channels.

Even with Orbi - the backhaul might be on one channel, but the clones will be on another, and generally there, it's a shared channel.

What happens with 20dB attenuation on the neighboring AP? Or 10dB for apartments...

Co-channel interference is a concern, but given that spreading loss is a 10LogR function with adjacent AP's

11n/11ac actually have decent co-channel interference thresholds - I'd hate for this to be a banner issue for things like 11b/11g - which was true there...
 
Could be possible. I checked with octoScope before posting the review. Have not heard anything back.

I've seen this uplink/downlink difference with 80 MHz bandwidth devices too. Usually four stream products.

BTW - nice on the retest - kind of thought something was up with the Octoscope STA's, just didn't make sense there.

The Intel STA driver - well, generally theyre pretty good in many circumstances, and a go-to driver for Linux - but the Chipset under test is relatively new, so some challenges for both Win and Linux there...
 
Well I can already say that when you choose the 160Mhz option on some devices the UI is not even allowing you to independently choose a control channel option when you set it 80+80 MHz or the 160 MHz frequency. But w/ that said I thought the whole thing w/ these new routers (and this new chipset) is that i didn't need an analyzer or channel to get best signal. It just seems counter productive to encourage ppl (that are trying to save money) to buy in-house equipment which already inherently produced to underperform.
 
According to my understanding from Apples Technical Wifi Specs the latest model MacBook Pros will only bond to two 80 Mhz channels. They don't support 160 Mhz. Does anyone know of any wifi boxes that have multiple 5 ghz 80 Mhz channels? Any mesh units?
 
Bonding 2 x 80mhz = 160mhz right?

Google 160mhz router or go with an AP that does 160mhz. It mostly comes down to budget and which version whether AC AX AX-E.

I have an AP that does 160 and AX and they run $150.
 
According to my understanding from Apples Technical Wifi Specs the latest model MacBook Pros will only bond to two 80 Mhz channels.

Nope...


They support 80/40/20 MHz channels in 11ac/11ax modes - no 160MHz support of any kind...
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top