Difficulties maintaining 160 MHz channel bandwidth

[Mutzli]

Does this switch actually do anything?

No matter how I set the channel bandwidth it always chooses the frequency the client wants to connect at. I thought setting this to 160MHz would only allow devices that support 160MHz to connect. But that is not the case, I still have devices connecting at 80MHz and 20MHz.

 

[John Fitzgerald]

Does this switch actually do anything?
View attachment 48953

No matter how I set the channel bandwidth it always chooses the frequency the client wants to connect at. I thought setting this to 160MHz would only allow devices that support 160MHz to connect. But that is not the case, I still have devices connecting at 80MHz and 20MHz.

How does DFS work: https://www.asus.com/support/FAQ/1045936

 

[SomeWhereOverTheRainBow]

Does this switch actually do anything?
View attachment 48953

No matter how I set the channel bandwidth it always chooses the frequency the client wants to connect at. I thought setting this to 160MHz would only allow devices that support 160MHz to connect. But that is not the case, I still have devices connecting at 80MHz and 20MHz.

Doesn't this type of nuance behavior have more to do with what control channel is selected?

There is a feature when using 160 MHz channel width in a 5 GHz Wi-Fi network: when the 160 MHz channel width is enabled, there are only two continuous blocks of channels that you can actually use - these are channels 36 to 64 and 100 to 128 (e.g., available with the Switzerland country code). Since a large channel width implies that the device will occupy the whole block of channels, there is no point in auto-choosing the channel in the Wi-Fi router's network settings.

So the goal would be to choose channels 36 (or 100 when possible) ?

 

[Mutzli]

Doesn't this type of nuance behavior have more to do with what control channel is selected?




So the goal would be to choose channels 36 (or 100 when possible) ?

It says range from 36 to 64, so any channel would work. But that is not my question. The scroll down selection of channels is what seems to be not doing anything. You can select a range of frequencies or a specific one. But no matter what frequency is selected the router - client connection behaves the same way. Once a frequency is negotiated with the client it keeps that for most of the time, unless it encounters a disturbance that negates a lower frequency.

Here is what I observed with the selection at 160MHz only:

It only seems to work from the lower frequency up. When I select 20MHz it's not connecting any client at 40, 80 or 160. But then why even offer single frequencies when the connection is always negotiated and occurs at any frequency below that? It would make more sense if the selection offered was 20MHz, 20/40MHz, 20/40/80MHz and 20/40/80/160MHz.

However, it would be great if the single frequency was working as the only one active. This way you could force clients to connect at a specific frequency only.

 

[RMerlin]

I thought setting this to 160MHz would only allow devices that support 160MHz to connect. But that is not the case, I still have devices connecting at 80MHz and 20MHz.

That's normal. Even a 20 MHz client can still connect to a router that has its radio set to 160 MHz - this setting only determines the max rate the radio can operate at, it does not determine what clients are allowed in. Clients will use as many streams as they can.

 

[Mutzli]

That's normal. Even a 20 MHz client can still connect to a router that has its radio set to 160 MHz - this setting only determines the max rate the radio can operate at, it does not determine what clients are allowed in. Clients will use as many streams as they can.

Then what's the difference between the two available settings: 20/40/80/160MHz and 160MHz?

 

[L&LD]

The router decides or you decide if 160MHz will be used.

 

[alan6854321]

Well, I thought I had it figured out... After a HW reset of the router (AX88u) and the nodes (2x AX86s) and putting humpty dumpty (AX88) back to tgether again (with all the scripts), the problem reappeared. I got a little aggressive when putting it back together, and after a few runs and reboots stopped my testing. After loading it all up with the scripts & settings I was running before 388.2 beta (and getting ~+900Mbps in both directions) and still seeing similar CPU utilization metrics before/after (single digits average utilization). The problem reappeared (dropping to ~+450Mbps Up / +~650Mbps Down or worse and packet loss). Some script or combination of them (more likely) or the CPU utilization of a particular script or combination of them (more likely), or overall how CPU resources are used has changed in this release.

So now going back and adding one by one, ligher CPU/WAN use scripts to heaviest, one by one, and testing after a reboot and letting it settle. When it goes south going to try and play around to see if uninstalling it or another clears it up. I also need to revaluate what scripts or combination of them to run to maintan as close to constant results as I used to get, or run them all and adjust how I use/view Speedtest results to judge router/carrier performance and preferably without impact to Wired/WiFi performance/errors (dropped packets!).

So far so good with the results with just these running, Skynet, scMerlin, spdMerlin, YazDHCP and vnStat. Of the remaining ones, scribe is the most intense from my list, and with that I can fool around with the loglevels to see how much of an impact that is, if there is one.

Are all these posts really relevant to this thread?

 

[RMerlin]

Then what's the difference between the two available settings: 20/40/80/160MHz and 160MHz?

It determines which channel width to setup on the router itself, which means how much bandwidth it can use, and how susceptible to interferences it will be. Using 20/40/80/160 is always better so the router can downgrade if there is too much interference.

 

[Mutzli]

It determines which channel width to setup on the router itself, which means how much bandwidth it can use, and how susceptible to interferences it will be. Using 20/40/80/160 is always better so the router can downgrade if there is too much interference.

That's my point, when I set it to 160MHz the connection width is the same as when on 20/40/80/160MHz. Clients use the same 4 frequencies on both settings since that 160MHz is not a fixed physical value.

 

[RMerlin]

That's my point, when I set it to 160MHz the connection width is the same as when on 20/40/80/160MHz.

This is what I'm trying to explain - that setting does not affect the client connection, it affects the channel width used by the router. It defines how wide the router's door is kept open, not the size of your clients going through that door.

 

[Krism]

It determines which channel width to setup on the router itself, which means how much bandwidth it can use, and how susceptible to interferences it will be. Using 20/40/80/160 is always better so the router can downgrade if there is too much interference.

When 160 is enabled my wifi connections become slugish and I have slow responses. When turned off, everyrhing is speedy fast and stable

 

[RMerlin]

When 160 is enabled my wifi connections become slugish and I have slow responses. When turned off, everyrhing is speedy fast and stable

Then your network has too much interference for 160 MHz to be usable, you will need to drop it to 80 MHz.

 

[jksmurf]

Then your network has too much interference for 160 MHz to be usable, you will need to drop it to 80 MHz.

For the average user, is this not something that Smart Connect does (or should do) automagically? Why does this need to be done manually?

I would imagine it has (should have?) a set of fixed parameters whereby if it doesn't make and hold that connection for a time period X, at throughput Y, it drops down to the next frequency level so as to optimize the average speed throughput over a fixed period? Is that how it it works?

Otherwise surely you would just end up with poor performance all round and it would be up and down all over the place?

 

[Krism]

Then your network has too much interference for 160 MHz to be usable, you will need to drop it to 80 MHz.

Okay, but when I looked at the wifi-info it was always on 80Mhz. I never saw it running at 160Mhz

 

[DJones]

For the average user, is this not something that Smart Connect does (or should do) automagically? Why does this need to be done manually?

I would imagine it has (should have?) a set of fixed parameters whereby if it doesn't make and hold that connection for a time period X, at throughput Y, it drops down to the next frequency level so as to optimize the average speed throughput over a fixed period? Is that how it it works?

Otherwise surely you would just end up with poor performance all round and it would be up and down all over the place?

If you leave it on this it might not force 160MHz when interference is too high. But as stated before 80Mhz will be much more accessible because their is more groups of 80Mhz channel availability then 160Mhz.

This is for the US. Canada only has 1 160MHz group. The second group under TDWR DFS isn’t allowed so it lacks the full space.

 

[RMerlin]

is this not something that Smart Connect does (or should do) automagically?

Smart Connect has nothing to do with radio configuration, it only serves in balancing clients between multiple radios.

All of this 80/160 MHz discussion should be moved elsewhere, it's totally unrelated to this beta thread.

 

[Ripshod]

I'm with @RMerlin in that this is not the place. But I do want to say one thing in an attempt to bring closure.
If you're not happy with ISM finally doing it's thing correctly and controlling DFS channels go back to an earlier firmware where it wasn't and be happy causing interference and suffering interference from others.
This is a working BETA!

 

[Tech9]

I believe sticking 160MHz wide channel in Asuswrt 386_46061 (and Asuswrt-Merlin 386.5_2) firmware for RT-AX86U (and other models) was actually a bug fixed in later firmware releases in order to better follow DFS channels use requirements. This change affects not only Asus routers, but anything else on the market using the same hardware and Broadcom drivers for it. This is not coming from Asus at all and totally unrelated to Asuswrt-Merlin.

 

[Dedel66]

No problem at all with 5GHz @ 160MHz with channel 48 fixed. When laptop connects to wlan, router switches to 160GHz. Some time after laptop is disconnected router switches back to 80MHz as expected - same with the node.

Bridge is working without any disconnects.

For me beta1 is a favourite as a release candidate.