ChannelHog - Monitor And Force Maximum 5GHz Bandwidth

[thiggins]

If DFS radar detection is as infrequent as you experience, then, yes I see the value.

How much real benefit do you get from 160 MHz channels?

 

[Adamm]

If DFS radar detection is as infrequent as you experience, then, yes I see the value.

Right. At first I assumed the router would handle this as part of the DFS implementation, but in two months of testing I realized otherwise.

How much real benefit do you get from 160 MHz channels?

I'd have to re-run my benchmarking for accurate results, but I with an AX200 wireless client I can get 1.5Gbps real world speeds, so I'd assume there would be a decent % margin difference staying on 80MHz channels.

 

[Kingp1n]

Is there a test script for the RT-AC86U orcan we use the same one?

 

[Adamm]

Is there a test script for the RT-AC86U orcan we use the same one?

It is currently only for the AX88U as its the only device with 160MHz channels.

 

[skeal]

I noticed wifi radar doesn't show any 160 stuff.

 

[sfx2000]

What do you mean? It detects the current channel width and if this is lower then expected it restarts the 5GHz radio which bumps up channel bandwidth to 160MHz as the firmware would instead leave it at 80MHz until manual intervention.

Without going into too much detail - chipset firmware inside the wireless chip runs it's own tests. You can send commands via the closed source driver, but it's an ask, not a directive - and it will ack the request to keep things from breaking userland.

 

[Adamm]

Without going into too much detail - chipset firmware inside the wireless chip runs it's own tests. You can send commands via the closed source driver, but it's an ask, not a directive - and it will ack the request to keep things from breaking userland.

I think your first post is a bit misleading (and to be fair comes across a little condescending). Clearly the method works in cases where 160MHz channels are feasible and the channel width had been knocked down to 80MHz due to DFS. I've been testing for two months without any side effects, much the same as if someone were to restart the wireless service via the WebUI (the reason I use the wl commands directly is because taking down just 1 band is less intrusive vs restarting the wireless service as a whole).

If you can post any actual grounds to why doing this is a bad idea I'm all ears, but so far both of your posts have been quite vague and lacking of substance.

 

[SwampKracker]

I think your first post is a bit misleading (and to be fair comes across a little condescending). Clearly the method works in cases where 160MHz channels are feasible and the channel width had been knocked down to 80MHz due to DFS. I've been testing for two months without any side effects, much the same as if someone were to restart the wireless service via the WebUI (the reason I use the wl commands directly is because taking down just 1 band is less intrusive vs restarting the wireless service as a whole).

If you can post any actual grounds to why doing this is a bad idea I'm all ears, but so far both of your posts have been quite vague and lacking of substance.

Why not just use the reboot scheduler at the same off-hours time? Simpler and will yield the same results.
Not criticizing your work, just noting that some people are already in the habit of rebooting on a schedule and would therefore be getting the same benefit as your ChannelHog script.

 

[Adamm]

Why not just use the reboot scheduler at the same off-hours time? Simpler and will yield the same results.
Not criticizing your work, just noting that some people are already in the habit of rebooting on a schedule and would therefore be getting the same benefit as your ChannelHog script.

Goes against the whole purpose of the script. This was designed to be unobtrusive (only restarting the necessary band), and secondly only do so when necessary rather then experience downtime every single day.

 

[L&LD]

@Adamm you certainly have a good script here and I intend to implement it myself on my own RT-AX88U soon.

The logic is sound and the reasons for this script do make it a useful addition to our arsenal for getting the most out of our networks. Thank you for this newest addition!

 

[thiggins]

Right. At first I assumed the router would handle this as part of the DFS implementation, but in two months of testing I realized otherwise.

There's nothing in DFS rules that says 160 MHz bandwidth can't be resumed (after the mandated time to stay off the channel where radar was detected. So ASUS could implement a rescan and restore of 160 MHz bandwidth if it wanted.

I'd have to re-run my benchmarking for accurate results, but I with an AX200 wireless client I can get 1.5Gbps real world speeds, so I'd assume there would be a decent % margin difference staying on 80MHz channels.

Are you talking link rate or actual throughput? How are you benchmarking?

My question is directed more at how you benefit from the higher throughput on one client when multiple clients (most not AX) are active,.

 

[skeal]

So ASUS could implement a rescan and restore of 160 MHz bandwidth if it wanted.

Seriously? Asus could implement a lot of fixes needed by a lot their routers, holding one's breath until they do, is not a productive method of resolve.

 

[skeal]

I thought it was one of the ideas of this website let alone this thread; to fine tune things and possibly find and make adjustments whether permanent or temporary.

 

[RMerlin]

Seriously? Asus could implement a lot of fixes needed by a lot their routers, holding one's breath until they do, is not a productive method of resolve.

ACSD is actually Broadcom's code, not Asus's. It's responsible for channel/bandwidth management.

 

[thiggins]

ACSD is actually Broadcom's code, not Asus's. It's responsible for channel/bandwidth management.

Thanks for the correction, Merlin.

 

[RMerlin]

A thought just occurred to me tho: I don't think the daemon does any rescan if channels are set to fixed instead of Auto. Maybe the lack of bandwidth upgrade is caused by using a fixed channel instead of an automatic one. Worth checking if you are affected by that issue (I'm not since I prefer to stay away from DFS channels).

 

[MDM]

A thought just occurred to me tho: I don't think the daemon does any rescan if channels are set to fixed instead of Auto. Maybe the lack of bandwidth upgrade is caused by using a fixed channel instead of an automatic one. Worth checking if you are affected by that issue (I'm not since I prefer to stay away from DFS channels).

And thus possibly linked to my question

 

[Adamm]

There's nothing in DFS rules that says 160 MHz bandwidth can't be resumed (after the mandated time to stay off the channel where radar was detected. So ASUS could implement a rescan and restore of 160 MHz bandwidth if it wanted.

Seems like the logical solution as the stay off time is only 30 minutes iirc.

Are you talking link rate or actual throughput? How are you benchmarking?

1.5Gbps actual throughput with a 2.4Gbps link-rate. For bench-marking I use my QNAP TVS-672XT with 3 gigabit connections to the router (2x in LACP / 1x in Single) as seen in this post. Alternatively I also run iperf directly off the router.

A thought just occurred to me tho: I don't think the daemon does any rescan if channels are set to fixed instead of Auto. Maybe the lack of bandwidth upgrade is caused by using a fixed channel instead of an automatic one. Worth checking if you are affected by that issue (I'm not since I prefer to stay away from DFS channels).

I'll give it a try over the next week or so and report back. Although it does still seem short sighted that this doesn't occur with a fixed channel.

 

[RMerlin]

I'll give it a try over the next week or so and report back. Although it does still seem short sighted that this doesn't occur with a fixed channel.

Could simply be something Asus didn't think of when deciding whether to start acsd or not.

Or I could be wrong, and the fallback is actually done by the wireless driver itself rather than acsd.

 

[Adamm]

A thought just occurred to me tho: I don't think the daemon does any rescan if channels are set to fixed instead of Auto. Maybe the lack of bandwidth upgrade is caused by using a fixed channel instead of an automatic one. Worth checking if you are affected by that issue (I'm not since I prefer to stay away from DFS channels).

I can confirm similar behavior happens when on auto settings, instead this time the router swapped over to channel 161 w/ 80MHz channel width and has stayed there for the last 8 hours. Seems like a pretty significant oversight in Asus's 160MHz implementation.