FYI/A: Bufferbloat 101

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
Which is true

cake is only meant , wired as it’s ping sensitive more which doesn’t mean one cannot use it

just that with all things equal, cake doesn’t account for the bad wifi unless it’s specific for lower bandwidth

good to see folks chiming in

I learned this only recently. BTW, the following is an interesting learning for me. Initially I thought cake-autorate can be used to deal with wireless bufferbloat, but apparently I was wrong.
https://github.com/lynxthecat/cake-autorate/issues/274#issuecomment-2034550854

Yeah, I think this is sub-optimal. Assuming your trie internet/WAN delay is well behaved you need a single cake instance per direction to control internet bufferbloat, and then deal with WiFi locally. The problems with WiFi are myriad:
a) WiFi is half duplex, and hence you need to run cake-autorate on all wirelessly connected devices and the AP
b) internet latency targets are unlikely to be ideal for a WiFi traffic shaper and vice versa
c) active measurements even with small ICMP packets waste an airtime slot, so have considerable side effects, especially if you consider a larger set of wifi connected devices...

In short, I would look for an airtime fairness/AQL capable WiFi-AP, that should deal with the AP to station bufferbloat decently. For the other direction you would need to fix the station's WiFi stack somehow... or hope that stations send far less than they receive...

+++++++++++

The following is a good summary as well.
https://forum.openwrt.org/t/how-openwrt-vanquishes-bufferbloat/189381

On Wireless Connections
Since OpenWrt is an access point, it can manage all the traffic flowing toward the many devices ("stations") that it serves. The "OpenWrt Wi-Fi Driver" uses the following mechanisms to reduce latency:

Individual transmit queues for each wireless station/client. Each queue ues fq_codel to control the amount of data queued for that station.

Airtime Fairness (ATF) to give each wireless client a fair share of the airtime as opposed to the number of bytes sent/received with ordinary Wi-Fi drivers. This ensures a low-rate (slow) station does not use up all the airtime (the so-called "WiFi anomaly"). ATF uses round-robin scheduling of all active stations to ensure they each use only their fair share of the available airtime.

Airtime Queue Limits (AQL) to prevent the chip hardware from queueing too much data for any one wireless station. Many wireless chipsets have significant (unnecessary) queueing. By default, AQL analyzes the actual bit rate for that station and ensures that no more than 12 msec of data is queued for it.

Modern OpenWrt supports the Wi-Fi driver for certain chipsets (Note: mainly mt76 and ath11k, in the future maybe ath12k).
+++++++++++++
 
Last edited:

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
8,096
Reaction score
2,015
I learned this only recently.
https://github.com/lynxthecat/cake-autorate/issues/274#issuecomment-2034550854

Yeah, I think this is sub-optimal. Assuming your trie internet/WAN delay is well behaved you need a single cake instance per direction to control internet bufferbloat, and then deal with WiFi locally. The problems with WiFi are myriad:
a) WiFi is half duplex, and hence you need to run cake-autorate on all wirelessly connected devices and the AP
b) internet latency targets are unlikely to be ideal for a WiFi traffic shaper and vice versa
c) active measurements even with small ICMP packets waste an airtime slot, so have considerable side effects, especially if you consider a larger set of wifi connected devices...

In short, I would look for an airtime fairness/AQL capable WiFi-AP, that should deal with the AP to station bufferbloat decently. For the other direction you would need to fix the station's WiFi stack somehow... or hope that stations send far less than they receive...
It’s still back to original wisdom: test it during peak for entire week.

then test without

It’s never been just theory and numbers only, it’s more trial and combination with solid test results from clean environment

just that some folks definitely over emphasised on pure lab numbers ( recently gotten into new hobby of IEM, same problem there )

End of the day,

be it asus default or ubiquity implementation of QoS

everyone just wish to have better internet, not just in terms of pure speed or low latency

but balance of all areas and slightly boost one area when needed

The next phase is to get better “m1 like chipset “ and AI calculation base on timings and ping for routers and all
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
I also took this opportunity querying there about Xiaomi Mi AIoT Router AX3600 i recently kapo cheap from carouhell and kpko on GL.iNET Flint 2 (GL-MT6000) . :grin:

@BradenHeat

Maybe you can try and see if your GL.iNet travel router supports ATL and AQF?

The answer of @hwzlite's question in OpenWRT forum about GL-MT6000 got answered.
https://forum.openwrt.org/t/gl-inet-flint-2-gl-mt6000-discussions/173524/994?u=dudez7

Code:
# iw list | grep 'TXQS\|AIRTIME_FAIRNESS\|AQL'
                 * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)
                * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)

New thread:
https://forum.openwrt.org/t/need-help-identifying-wi-fi-chipsets/193862
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
The next phase is to get better “m1 like chipset “ and AI calculation base on timings and ping for routers and all

The new WiFi 7 chipsets from Qualcomm/Broadcom/MediaTek seem to have NPU or similar things built-in. So maybe they can do better. Still the wireless chipset driver needs to be officially supported by Linux and OpenWRT first.

As of now, no official OpenWRT support for any of the WiFi 7 routers, even though Qualcomm/MediaTek may provide OpenWRT based SDK to the router vendors. Not so sure about Broadcom's SDK.

Reference:
1) Qualcomm QSDK -- QSDK is based upon the OpenWrt 19.07 and 23.05.
https://wiki.codelinaro.org/en/clo/qsdk/overview

2) Banana Pi R4 WiFi 7 development board using MTK Filogic 880
https://www.mediatek.com/blog/banan...lopment-board-powered-by-mediatek-filogic-880
 

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
8,096
Reaction score
2,015
@BradenHeat

Maybe you can try and see if your GL.iNet travel router supports ATL and AQF?
Left it in office la

need to check Monday on wards lols

but I doubt so since theres nothing mentioned, but got me curious for sure
@BradenHeat

Maybe you can try and see if your GL.iNet travel router supports ATL and AQF?

The answer of @hwzlite's question in OpenWRT forum about GL-MT6000 got answered.
https://forum.openwrt.org/t/gl-inet-flint-2-gl-mt6000-discussions/173524/994?u=dudez7

Code:
# iw list | grep 'TXQS\|AIRTIME_FAIRNESS\|AQL'
                 * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)
                * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)

New thread:
https://forum.openwrt.org/t/need-help-identifying-wi-fi-chipsets/193862


just for others,

TXQS (Traffic Queue Selectors):

  • Function: TXQS are essentially queues that hold packets waiting to be transmitted over the wireless network. Different types of traffic (e.g., gaming, video streaming, web browsing) might be placed in separate TXQs for better organization.
FQ-CoDel (Fair Queueing with CoDel):

  • Function: FQ-CoDel is a queuing algorithm implemented within TXQs. It prioritizes low-latency traffic while preventing bufferbloat, a phenomenon that causes delays even when overall bandwidth isn't maxed out. This ensures smoother performance for applications like gaming and video conferencing.
AQL (Airtime Queue Limits):

  • Function: AQL sets limits on the amount of airtime each device on the network can utilize for transmitting data. This ensures fairness by preventing any single device from dominating airtime and slowing down others. It's particularly beneficial in congested networks with many devices competing for bandwidth.
AIRTIME_FAIRNESS:

  • Function: Airtime fairness scheduling is a broader concept that encompasses mechanisms like AQL. It aims to allocate airtime (the time it takes to transmit a packet) fairly among all connected devices. This ensures optimal network utilization and minimizes lag for all users.
In essence:

  • TXQs organize traffic.
  • FQ-CoDel prioritizes low-latency traffic within TXQs.
  • AQL sets limits on airtime usage for individual devices.
  • Airtime fairness scheduling is the overarching concept ensuring fair allocation of airtime.
  • pen_spark




The new WiFi 7 chipsets from Qualcomm/Broadcom/MediaTek seem to have NPU or similar things built-in. So maybe they can do better. Still the wireless chipset driver needs to be officially supported by Linux and OpenWRT first.

As of now, no official OpenWRT support for any of the WiFi 7 routers, even though Qualcomm/MediaTek may provide OpenWRT based SDK to the router vendors. Not so sure about Broadcom's SDK.

Reference:
1) Qualcomm QSDK -- QSDK is based upon the OpenWrt 19.07 and 23.05.
https://wiki.codelinaro.org/en/clo/qsdk/overview

2) Banana Pi R4 WiFi 7 development board using MTK Filogic 880
https://www.mediatek.com/blog/banan...lopment-board-powered-by-mediatek-filogic-880


Hopefully, the implementation and standardzation for minimum wifi 7 certification includes NPU, because, the less the end user has to fumble, the better.

of course, it would be ideal to have openwrt with full control, and i doubt anytime soon.
 

hwzlite

Master Member
Joined
Jan 27, 2007
Messages
3,069
Reaction score
3,214

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
2) FlexQoS on ASUSWRT-Merlin.
Flexible QoS Enhancement Script for Adaptive QoS on ASUSWRT-Merlin.
Okay with 1Gbps. I have not tried it myself.
https://github.com/dave14305/FlexQoS

Note from github.
Options for Queue Discipline
Default: FlexQoS works with the default QoS queue disciplines setup by the Adaptive QoS engine. As of Merlin v386.1, only Stochastic Fair Queuing (sfq) is supported in combination with Hierarchical Token Bucket (htb). Earlier versions of Merlin allow the selection of a queue discipline on the QoS page.

fq_codel: FlexQoS offers the option to override the QoS queue discipline structure by replacing the second-level htb structure with the fq_codel queue discipline.

Info from my Asus RT-AX86U
Bash:
xiaofan@RT-AX86U-2D40:/tmp/home/root# tc qdisc ls
qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 2: dev eth0 parent 1:2 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 10: dev eth0 parent 1:10 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 1256: dev eth0 parent 10:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 11: dev eth0 parent 1:11 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 2256: dev eth0 parent 11:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 12: dev eth0 parent 1:12 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 3256: dev eth0 parent 12:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 13: dev eth0 parent 1:13 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 4256: dev eth0 parent 13:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 14: dev eth0 parent 1:14 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 5256: dev eth0 parent 14:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 15: dev eth0 parent 1:15 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 6256: dev eth0 parent 15:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 16: dev eth0 parent 1:16 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 7256: dev eth0 parent 16:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 17: dev eth0 parent 1:17 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 8256: dev eth0 parent 17:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 1003: dev eth0 parent 10:3 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 2003: dev eth0 parent 11:3 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 3003: dev eth0 parent 12:3 limit 127p quantum 1514b depth 127 divisor 1024
...
qdisc sfq 7007: dev eth0 parent 16:7 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 8007: dev eth0 parent 17:7 limit 127p quantum 1514b depth 127 divisor 1024
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth4 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev spu_us_dummy root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev spu_ds_dummy root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth7 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev br0 root refcnt 2 r2q 10 default 0 direct_packets_stat 209 direct_qlen 2
qdisc sfq 2: dev br0 parent 1:2 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 10: dev br0 parent 1:10 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 1256: dev br0 parent 10:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 11: dev br0 parent 1:11 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 2256: dev br0 parent 11:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 12: dev br0 parent 1:12 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 3256: dev br0 parent 12:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 13: dev br0 parent 1:13 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 4256: dev br0 parent 13:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 14: dev br0 parent 1:14 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 5256: dev br0 parent 14:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 15: dev br0 parent 1:15 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 6256: dev br0 parent 15:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 16: dev br0 parent 1:16 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 7256: dev br0 parent 16:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc htb 17: dev br0 parent 1:17 r2q 10 default 0x256 direct_packets_stat 0 direct_qlen 2
qdisc sfq 8256: dev br0 parent 17:256 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 1003: dev br0 parent 10:3 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 2003: dev br0 parent 11:3 limit 127p quantum 1514b depth 127 divisor 1024
...
qdisc sfq 7007: dev br0 parent 16:7 limit 127p quantum 1514b depth 127 divisor 1024
qdisc sfq 8007: dev br0 parent 17:7 limit 127p quantum 1514b depth 127 divisor 1024
 

hwzlite

Master Member
Joined
Jan 27, 2007
Messages
3,069
Reaction score
3,214

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
Have contributed my findings there.
Where I managed to get another Xiaomi AX3000T cheap $10 from carousel.
But its firmware is currently only available in snapshots with frequent commit changes... really will get OCD if wanna keep tracking/updating it... :s22:

Nice contributions. (y)

I think you have done the contribution and can wait for a while -- no need to catch up with the snapshot release too often.
https://forum.openwrt.org/t/need-help-identifying-wi-fi-chipsets/193862/3

ChipsFeaturesRouterFirmware
Qualcomm Atheros IPQ8074 (QCN5024,QCN5054)TXQSXiaomi Mi AIoT Router AX360023.05.3
Qualcomm Atheros QCA9889TXQS/ATF/AQLXiaomi Mi AIoT Router AX360023.05.3
MediaTek MT7976CNTXQS/ATF/AQLXiaomi AX3000TSNAPSHOT r25829-e6f7e9dca9
MediaTek MT7615NTXQS/ATF/AQLLinksys EA810023.05.3

BTW, you are very good at finding lobangs. :LOL:
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
All hail low-ballers!
Just kidding, the cool seller offered swee starting price of $10 :cool:
Btw I revised the first row, thx.

Nice.

Other than the ones you have, it will be interesting to look at some other popular routers supported by OpenWRT.
https://openwrt.org/toh/views/toh_available_16128_ax-wifi

The following lists only the main CPU chipset and not the WiFi chipset.

Not that interesting: MT7621/MT7621A
Asus RT-AX53U, MT7621A
TP-Link Archer AX23, MT7621

Slightly better: MT7622B/MT7621BV
Xiaomi AX3200 (got local version and China version), MT7622B
D-Link EAGLE PRO AI M32, MTK MT7622BV
D-Link EAGLE PRO AI R32, snapshot release, MTK MT7622BV
Linksys E8450 -- MTK MT7622BV

More interesting: MTK Filogic 820/830, Qualcomm Atheros ath11k
Asus TUF-AX4200, MTK Filogic 830
Asus TUF-AX6000, snapshot release, MTK Filogic 830
Xiaomi AX9000 (got local version and China version), Qualcomm Atheros IPQ8072A
Xiaomi Redmi AX6000, MTK Filogic 830
GL.iNET GT-X3000, snapshot release only, MTK Filogic 820
GL.iNET GL-MT3000, MTK Filogic 820
GL.iNET GL-MT6000, MTK Filogic 830
Linksys MX4200 Velop triband, snapshot release only, Qualcomm IPQ8174

In the future -- WiFi 7 chipsets from MediaTek and Qualcomm. Unlikely OpenWRT will ever get good support of Broadcom WiFi chipsets.
 

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
8,096
Reaction score
2,015
@BradenHeat

Maybe you can try and see if your GL.iNet travel router supports ATL and AQF?

The answer of @hwzlite's question in OpenWRT forum about GL-MT6000 got answered.
https://forum.openwrt.org/t/gl-inet-flint-2-gl-mt6000-discussions/173524/994?u=dudez7

Code:
# iw list | grep 'TXQS\|AIRTIME_FAIRNESS\|AQL'
                 * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)
                * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)

New thread:
https://forum.openwrt.org/t/need-help-identifying-wi-fi-chipsets/193862


guess not =/




wonder if i could install it or its hardcoded via biosfirmware hmmmm
 

hwzlite

Master Member
Joined
Jan 27, 2007
Messages
3,069
Reaction score
3,214
guess not =/




wonder if i could install it or its hardcoded via biosfirmware hmmmm



Some hints from https://forum.openwrt.org/t/gl-inet-gl-axt1800-slate-ax/175825/3 :

slh
Oct 2023

Someone will have to get the qualcommax/ipq60xx (sub-)target off the ground, that is the major burden (and there's still a lot left to do for that). Once that is finished, adding additional ipq60xx devices is relatively simple in comparison. Sadly QCA isn't really good at mainlining (or even testing!) their SOC support, leaving a lot that needs fixing (their QSDK with its own kernel v4.4.60 is very different from anything that could be merged into OpenWrt and maintained long term).
…and no, the referenced pull request against Telecominfraproject doesn't help with this in the slightest, as they take the cheap route out of using the QSDK underneath.

There is some commit ipq60xx development in OpenWRT , but no official snapshots built for gl-axt1800 yet... :unsure:
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
guess not =/




wonder if i could install it or its hardcoded via biosfirmware hmmmm

I see. I think this is because you are running vendor firmware from GL.iNET.

Unfortunately no official OpenWRT support yet for your router. Only the following 4 WiFi 6 routers from GL.iNet are supported now (two with only snapshots release).

PgDZOjA.jpeg


There are unofficial OpenWRT build here in the OpenWRT forum.
https://forum.openwrt.org/t/gl-inet-ax1800-new-router-openwrt-support/105163/478

GL-AX1800 (Flint)
Whats working :

  • LAN
  • WAN
  • WiFi
  • USB
  • Reset Button
  • WPS/Sync (Assigned as WPS)
Whats not working:

  • Please let me know
GL-AXT1800 (Slate AX)
Whats Working:

  • LAN
  • WAN
  • WiFi
  • SDCARD
  • USB
  • FAN (Please read further down)
  • Toogle (Assigned as WPS)
Whats not working:

  • Fan_control doesn't start on boot known issue open ssh and execute /etc/init.d/fan_control start
Important!: The fan control now controls the fan speed to the following temp markers and fan speed.

Temp = Percentage (Value in cur_state)
45c = 0% (0) Fan speed
58c = 50% (128) Fan speed
85c = 100% (254) Fan speed

The fan tuning will be required and over time it will be adjusted. However for now it should be sane enough. The fan_monitor in /usr/sbin/ is where the fan speeds and temp markers are at and can be edited with vim If you have a suggestion that is better please let me know.

Testing
What needs to be checked:

  • Fan works correctly after running /etc/init.d/fan_control start in SSH
  • WiFi is stable (Speedtests and logs please)
  • VPN Performance (Speedtest please and logs , OpenVPN and Wireshark)
Thanks to @anomeome for the fan script!

Solutions

  • Fan boots at 100% ssh or open Terminal in LUCI then issue echo "0" > /sys/devices/virtual/thermal/cooling_device0/cur_state " this stop the fan but allow the monitor to continue controlling the fan.
 

BradenHeat

Supremacy Member
Joined
Apr 4, 2005
Messages
8,096
Reaction score
2,015
I see. I think this is because you are running vendor firmware from GL.iNET.

Unfortunately no official OpenWRT support yet for your router. Only the following 4 WiFi 6 routers from GL.iNet are supported now (two with only snapshots release).

PgDZOjA.jpeg


There are unofficial OpenWRT build here in the OpenWRT forum.
https://forum.openwrt.org/t/gl-inet-ax1800-new-router-openwrt-support/105163/478

GL-AX1800 (Flint)
Whats working :

  • LAN
  • WAN
  • WiFi
  • USB
  • Reset Button
  • WPS/Sync (Assigned as WPS)
Whats not working:

  • Please let me know
GL-AXT1800 (Slate AX)
Whats Working:

  • LAN
  • WAN
  • WiFi
  • SDCARD
  • USB
  • FAN (Please read further down)
  • Toogle (Assigned as WPS)
Whats not working:

  • Fan_control doesn't start on boot known issue open ssh and execute /etc/init.d/fan_control start
Important!: The fan control now controls the fan speed to the following temp markers and fan speed.

Temp = Percentage (Value in cur_state)
45c = 0% (0) Fan speed
58c = 50% (128) Fan speed
85c = 100% (254) Fan speed

The fan tuning will be required and over time it will be adjusted. However for now it should be sane enough. The fan_monitor in /usr/sbin/ is where the fan speeds and temp markers are at and can be edited with vim If you have a suggestion that is better please let me know.

Testing
What needs to be checked:

  • Fan works correctly after running /etc/init.d/fan_control start in SSH
  • WiFi is stable (Speedtests and logs please)
  • VPN Performance (Speedtest please and logs , OpenVPN and Wireshark)
Thanks to @anomeome for the fan script!

Solutions

  • Fan boots at 100% ssh or open Terminal in LUCI then issue echo "0" > /sys/devices/virtual/thermal/cooling_device0/cur_state " this stop the fan but allow the monitor to continue controlling the fan.

well once im in my free time to dismantle the thing and backup the original image, then i shall try lol , seems like another trial case XD
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
35,531
Reaction score
11,932
@hwzlite
Now that you get faster WiFi 6 router Xiaomi AX3600 and Xiaomi AX3000T (compared to the old Linksys EA8100 v1), maybe you can try and test with them to see if you get faster speed and yet can retain the good bufferbloat testing results mentioned below.
https://forums.hardwarezone.com.sg/threads/fyi-a-bufferbloat-101.6427979/page-11#post-151519973

From :
https://forums.hardwarezone.com.sg/...what-they-claim.7006382/page-2#post-152000908
 

hwzlite

Master Member
Joined
Jan 27, 2007
Messages
3,069
Reaction score
3,214
@hwzlite
Now that you get faster WiFi 6 router Xiaomi AX3600 and Xiaomi AX3000T (compared to the old Linksys EA8100 v1), maybe you can try and test with them to see if you get faster speed and yet can retain the good bufferbloat testing results mentioned below.
https://forums.hardwarezone.com.sg/threads/fyi-a-bufferbloat-101.6427979/page-11#post-151519973

From :
https://forums.hardwarezone.com.sg/...what-they-claim.7006382/page-2#post-152000908


Sure , once i upgrade my M1 500Mbps to 1Gbps ;)
 
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ Forums. Forum members and moderators are responsible for their own posts. Please refer to our Community Guidelines and Standards and Terms and Conditions for more information.
Top