160 MHz stability

[Morpheus2020]

36/160 does not use the weather rader channels, 120-128.

View attachment 42905

OE

I remember that 100/160 also appeared in less than 3 minutes after the router was turned on. But I'm not sure. This may be related to the "region" setting.

 

[ColinTaylor]

I remember that 100/160 also appeared in less than 3 minutes after the router was turned on. But I'm not sure.

That would be the case if the channel bandwidth were set to 80MHz, but not 160MHz.

This may be related to the "region" setting.

Possibly, if you're in one of the more "obscure" countries.

 

[OzarkEdge]

I remember that 100/160 also appeared in less than 3 minutes after the router was turned on. But I'm not sure. This may be related to the "region" setting.

Notice the 10min TWDR scan time noted on the channel plan. I have not timed it since I can't use DFS control channels with some of my devices... I can only use bands 1,2a with non-DFS control channels 36-48.

OE

 

[xnknown]

I think this question may have been missed as it was originally sandwiched between some (now removed comments). Regardless, if you look at RMerlin's posted (image/graph) in #12 above... Look where ch128 is situated? + with some of those favoring 160MHz usage, I think they are possibly overlooking the time duration of the interruptions to their 5G signal.
For example) I have noticed that with DFS/160MHz enabled my 5G radios take considerably longer to become available whenever the router tries to re-initialize the radios.
(Noticeable after reboots, or changes to network configs.)
This delay can easily be observed.
On a disconnected networked device just scan the SSIDs... the 5G radio will not be available for a while.
I think it's caused by the additional overhead required by the router to check if 160MHz is available.
Next, disable the 160MHz & you will "most likely" notice your 5G radio becomes available just as quickly as the 2.4-radio.
IMO if my WiFi is going to "occasionally" drop clients (due to radar detection) & ALSO take longer to make the radio available to my network devices... Doesn't it mean my wifi is LESS stable???
+
Another point about 160MHz & speed in general.
Protos seemed to favor car analogies so...
If we think of all our devices(network-cards) as: CARS & the WiFi-Router the Racetrack.
In most cases the majority of clients are not, racecars.
Trying to drive them at max-speeds can exceed their capabilities & often cause them to crash.
Yeah, you can definitely make a fast device whip around your network.
But it often comes at a cost.
That cost is LESS stability & likely more crashes for the non-racecars on the (track/network)
Ex) My Google ______s keep disconnecting

It definitely noticed it takes longer to initialize at boot then but I've noticed no overall stability issues over 80mhz, for me at least 160 has far improved speed no issues whatsoever. But I live in a neighborhood with almost no decent router so I could have very little interference from anyone. I'm just not sure what the actual benefit is over choosing channel 36 which I've seen a lot of people say is necessary for 160 rather then just choosing a channel at random

 

[Morpheus2020]

That would be the case if the channel bandwidth were set to 80MHz, but not 160MHz.


Possibly, if you're in one of the more "obscure" countries.

Not 80MHz, but 20/40/80/160MHz.
I forgot the details of the test. I'll retest after RMerlin releases 386.7.2.

 

[TheLyppardMan]

One of the first things I do when doing a clean install of a firmware upgrade or setting up a new router is to set the 2.4 band to 20MHz and the 5G band to 20/40/80 MHz. I've never wanted to try to use the 160MHz because even with my limited knowledge, I know that it is likely to cause problems and I get excellent speeds on 5G anyway.

 

[Tech9]

One more instance of rude behavior and/or personal attacks

I did not offend nor attack anyone. Read post #4 where the escalation starts and no action was taken. It’s still there. Stop threatening me, please. Thank you.

 

[TheLyppardMan]

I thought we were all supposed to be kind to one another and help each other as best we can. It's very sad to see insults flying around, no matter who is responsible and it doesn't achieve anything useful in the end. I'm not very clever and much of what is talked about on a forum like this goes over the top of my head, but I want you all to know that I really appreciate the time and effort you put in to try to help others and I'm sure most forum members would feel this way too.

 

[Tech9]

If you are talking to me, I’m done with this thread. There is plenty of technical information presented above, enough for everyone to set more realistic expectations.

 

[Morris]

i have my 160mhz turned on and set to channel 128 its working fine, is there a reason why it should be set to 36?

No, you do not have to change anything. You are on CH 100-128 with 128 the Control Channel.

 

[SAL9K]

I'm on stock f/w 49599, with all default wireless settings on 5g, and router has been stuck on 161/80 for a few days now. On previous stock f/w 49447, it would gladly go back to [36,48]/160 if one of my (two total) intel ax200 clients were on, but no more.

I get the below every 15-30 in the system log:

Jul 18 13:28:53 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jul 18 13:28:53 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jul 18 13:28:53 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jul 18 13:28:53 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jul 18 13:28:53 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jul 18 13:28:53 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jul 18 13:28:53 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jul 18 13:28:53 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jul 18 13:28:53 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jul 18 13:28:53 acsd: acs_candidate_score_intf(1108): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jul 18 13:28:53 acsd: acs_candidate_score_bgnoise(1573): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jul 18 13:28:53 acsd: acs_candidate_score_txop(1831): eth7: txop check failed for chanspec: 0xeb32 (48/160)

And also this in the wireless log, *never* changes:

Interference Level: Acceptable
Mode    : AP Only

DFS status: state IDLE time elapsed 0ms radar channel cleared by DFS channel 36/160 (0xE832)

It seems like DFS channels aren't being scanned as normal any longer on this f/w, hence always showing "0ms"? Anyone else see this?

I'm more curious here, than complaining, as 80MHz is plenty fast for my usage, and the ax86u has been rock stable ever since I got a year ago. Would be nice though to fully exercise the ax200.

 

[Morris]

It definitely noticed it takes longer to initialize at boot then but I've noticed no overall stability issues over 80mhz, for me at least 160 has far improved speed no issues whatsoever. But I live in a neighborhood with almost no decent router so I could have very little interference from anyone. I'm just not sure what the actual benefit is over choosing channel 36 which I've seen a lot of people say is necessary for 160 rather then just choosing a channel at random

What @OzarkEdge pointed out regarding the UNI 2a band is partially correct. CH 52-64 are DFS channels yet allowed indoors at lower power even if there are aircraft in the area. This further reduces the range of the already shorter range 5-Ghz band and depending on distances the result can be reduced throughput. Also, FCC regulations (I think part A or B) requires any device that is interfering with rally regulated communications to be turned off or remediated. There for many WiFi AP manufactures chose to depart UNI 2a rather than risk a fine.

 

[Morris]

That would be the case if the channel bandwidth were set to 80MHz, but not 160MHz.


Possibly, if you're in one of the more "obscure" countries.

It's 60 seconds of listening before transmitting on any DFS channel no matter what the channel width, even 20 Mhz. If Weather Radar is detected, then transmission on that channel must immediately halt and before using it again there must be 10 minutes of silence.

 

[ColinTaylor]

It's 60 seconds of listening before transmitting on any DFS channel no matter what the channel width, even 20 Mhz. If Weather Radar is detected, then transmission on that channel must immediately halt and before using it again there must be 10 minutes of silence.

Maybe the rules have changed in the US. In the post I was replying to he stated 100/160 which includes the weather radar channels (120-128). It is a legal requirement in the EU that the router listens for at least 10 minutes on those radar channels before transmitting. This is what my RT-AX86U does on startup.

 

[Morris]

Maybe the rules have changed in the US. In the post I was replying to he stated 100/160 which includes the weather radar channels (120-128). It is a legal requirement in the EU that the router listens for at least 10 minutes on those radar channels before transmitting. This is what my RT-AX86U does on startup.

I'm in the US and don't know the EU regulations. All of this is for our safety.

I've seen DFS go very wrong where my router did not hear the weather radar so it did not leave the DFS channel. My Windows Laptop with Intel NIC refused to connect to the DFS channel and instead connected on 2.4 Ghz. That was the last straw for me and I turned off DFS and also went 80 wide. I've been very stable since and the difference in throughput is tiny, possibly 10% faster on 160 wide.

 

[TheLyppardMan]

I'm in the US and don't know the EU regulations. All of this is for our safety.

I've seen DFS go very wrong where my router did not hear the weather radar so it did not leave the DFS channel. My Windows Laptop with Intel NIC refused to connect to the DFS channel and instead connected on 2.4 Ghz. That was the last straw for me and I turned off DFS and also went 80 wide. I've been very stable since and the difference in throughput is tiny, possibly 10% faster on 160 wide.

I do think that there is a bit of an obsession with speed and a feeling that whatever technology delivers in the future, there will be some who won't be satisfied. You see the same situation on the roads - we can travel faster than anyone could ever dream of in the past and yet you still see some folks racing past at well above the speed limits. There are more important things to think about in the age in which we live than whether we can squeeze a little bit more out of our internet connections. Only a few decades ago, we didn't even have the internet and it concerns me that we are becoming ever-dependant on it, almost to the point of obsession. Example: I recently saw a schoolboy riding his pushbike with no hands on the handlebar and watching his phone instead of where he was going. One defect in the pavement (of which there are many around where I live) and he could have had a nasty surprise. I'm not saying we shouldn't enjoy technology and the benefits it brings, but we shouldn't let it take over our lives.

 

[Morris]

I do think that there is a bit of an obsession with speed and a feeling that whatever technology delivers in the future, there will be some who won't be satisfied. You see the same situation on the roads - we can travel faster than anyone could ever dream of in the past and yet you still see some folks racing past at well above the speed limits. There are more important things to think about in the age in which we live than whether we can squeeze a little bit more out of our internet connections. Only a few decades ago, we didn't even have the internet and it concerns me that we are becoming ever-dependant on it, almost to the point of obsession. Example: I recently saw a schoolboy riding his pushbike with no hands on the handlebar and watching his phone instead of where he was going. One defect in the pavement (of which there are many around where I live) and he could have had a nasty surprise. I'm not saying we shouldn't enjoy technology and the benefits it brings, but we shouldn't let it take over our lives.

One lovely spring day I was out for a walk. As I returned home, I found all of my neighbors hurtled around a utility pole. When I asked what was going on they stated they had no TV or Internet because a car had hit the pole cutting the power to the cable repeater. I chatted with them for a bit and then continued my walk.

 

[OzarkEdge]

What @OzarkEdge pointed out regarding the UNI 2a band is partially correct. CH 52-64 are DFS channels yet allowed indoors at lower power even if there are aircraft in the area.

I'm not sure what I pointed out besides posting a channel plan by other for reference.

Here's another one from the FCC-US... it's hard to find their information and to know what is current and what actually applies for given or required conditions like master/client, indoor/outdoor, xdBi antenna gain, etc. etc. etc.... radio is hard:

For instance, the above shows U-NII-1,2a,2c band max Tx Power is 250mW for clients... the lowest common denominator for both non-DFS and DFS channels in those bands... maybe, it's hard to be sure what the current rules are. Only U-NII-3 band permits 1000mW Tx power for both master and client devices.

OE

 

[capncybo]

It's 60 seconds of listening before transmitting on any DFS channel no matter what the channel width, even 20 Mhz. If Weather Radar is detected, then transmission on that channel must immediately halt and before using it again there must be 10 minutes of silence.

This is definitely worth writing down somewhere. Thanks Morris.
+
"CH 52-64 are DFS channels yet allowed indoors at lower power even if there are aircraft in the area. This further reduces the range of the already shorter range 5-Ghz band"
Superb knowledge, thank you.

 

[thiggins]

Any channel group that includes the weather radar channels requires the router to wait at least 10 minutes to ensure it is clear. For the other DFS channels the wait time is only 60 seconds.

See Table 1 here.

SmallNetBuilder's Wi-Fi Dynamic Frequency Selection (DFS) FAQ - SmallNetBuilder

What is Dynamic Frequency Selection (DFS) and why should you care? Here's the straight poop.

www.smallnetbuilder.com

Specs say Channel Availability Check (CAC) must be "at least" 60 seconds in US and EU. The 10 minute CAC is required only in Canada and Australia and only for 5600-5650 MHz.