MT6000 custom build with LuCi and some optimization - kernel 6.6.x

When you activate iBF eBF go to 0...

So I made another round of testing upgrading to the latest build.

Having to wait 10 minutes for the 5g to be online is not ideal especially when testing. Why this limit?

Either way, I am affected by bufferbload when using WiFi. Using LAN, I get A+ with a single digit latency change. In WiFi I get from +30 to +100, depending on the client and the speed, with a score of B to C.

I have a 2.5Gbit down and 500 up, do I really need to enable SQM or I am missing something else?

Honestly I don't remember if I checked bufferbloat in WiFi with the last build, but I haven't changed those settings. Toggling iBF doesn't make a difference.

Do you have WED enabled or disabled?

@pesa1234 When you have a moment, would you mind taking a look at this test and see if you agree that enabling WED by default may not be the most ideal configuration due to its impact on AQL?

1 Like

@auanasgheps
Wed with sqm script is not compatible.
Do you have sqm enabled? settings?

What about packet steering?

Can you please share more info regarding your settings? WED-packet steering sqm etc...

PPoE?

With 2.5gbit/s and 500up I don't think is necessary sqm...

Thanks

I'll take a look and I check, thanks for sharing

2 Likes

No, I haven't enabled SQM, because I've read that isn't needed with such high speeds. And this stands true for ethernet where I get a score of A or A+.

I haven't touched any WED setting so I guess is enabled.

My settings:

  • Hardware and Software Flow Offloading Enabled
  • Packet Steering Enabled (first option), Steering Flows 128
  • iBF on or off, no difference so I kept it on.
  • WAN PPPoE IPv4 and IPv6 (native)

Latency increases with speed: with a WiFI6 80mhz client it is about 40/50 ms, with a WIFI6 160mhz gets to 70/100 ms during download.

1 Like

Thanks for your answer, can you post cpu load under speed test. Htop

Wpa2 or wpa3?

1 Like

WPA3.
I can't do a screen right now but I remember the load is distributed to all CPUs and is very low, under 5%.

Ok, thanks a lot

As @_FailSafe suggest let me compile a new firmware with different aql

2 Likes

Yeah, I'm a huge fan of the idea of having WED available for unique situations where it would be beneficial. But generally, I am a firm believer that lower latency (by not bypassing/hampering AQL) is the key to better UX and those that really need higher bandwidth over WiFi can opt in to additional settings (like WED) when needed. :+1:t2:

2 Likes

It WED is supposedly causing such high latency, what benefit would bring? Higher WiFi throughput?

I can try disabling WED in the next few days and report back.

Not necessarily higher throughput, but equivalent throughput at lower (almost negligible) CPU usage. However, if one is running into regular CPU contention that is affecting wireless throughput with WED disabled, then enabling WED in that case would likely fix the wireless throughput issue, but at the expense of losing AQL advantages.

New round of testing.
Same conditions as before, I can confirm with htop very little CPU load spread across all corse when running a WiFi bufferbloat test

  • Galaxy S23: +76 ms download, +59 upload. Score: C
  • Oneplus 8T: + 68 ms download, +40 upload. Score: C (this client is only 80mhz so is slower, hence slightly less latency).

No other device is on the network, since I'm using a different SSID of my usual one.

I disabled WED by going to /etc/modules.d/mt7915e and removinremoved wed_ename=1 as instructed by pesa in a previous post, then rebooted.
immagine

I don't think the change made any effect because I'mn getting the very same latency and CPU load hasn't increased.

SQM is disabled

I have to go to my usual setup, but tomorrow I'll be able to do more testing after your replies :slight_smile:

EDIT: I made a last test for today, reflashing the build I previously tested which is r26028.
Got the same results.

1 Like

What is the output of this command?
cat /sys/module/mt7915e/parameters/wed_enable

If it says Y, then try modifying /etc/modules.conf to include this line (and obviously reboot after that):
options mt7915e wed_enable=N

i.e.:

root@AP:~# cat /etc/modules.conf
# examples:
# options mod1 option=val
# blacklist mod2
options mt7915e wed_enable=N

After the reboot, confirm this command returns an N:
cat /sys/module/mt7915e/parameters/wed_enable

Once that is confirmed, run the following to temporarily change your AQL limits to 1500 and then retry your bufferbloat test(s):

aql_txq_limit=1500
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done

If you like the results, add those three lines into your /etc/rc.local file in order for them to survive reboots.


Update 1:
The suggested AQL changes above are only needed in the interim until @pesa1234's next (r2.4) release. @pesa1234 has some really great changes (here and here) that will negate the need to manually tweak these AQL values for the majority of users. :clap:t2:

4 Likes

I'm checking a new build with some improvement for ping and dfs, if it's all ok, it will be online in the afternoon, could you please check if I'm going in a good direction?

At the moment I get only +5ms of ping.

Thanks

2 Likes

I'm available to do some testing later today with the new build when you'll share it.

Since I'm using this router only for testing (for now) I can wipe/upgrade when I want.

Bravo! Sounds like this is all heading in a very positive direction!

@dtaht See @pesa1234's upcoming changes here:

2 Likes

Thanks to @_FailSafe and to @dtaht I have inserted their suggestion for AQL and codel params.

Decreased the boot time of 5ghz to 3 minutes, less give me issues on dfs channels @thedude

Added the possibility in Luci to enable radar background and also added the chanlists when you enable it (if you are not in auto it is mandatory)

Added a patch related to background radar from mtk:
When background radar is enabled and bandwidth is set to 160, AP will fail to startup due to the lack of non-DFS channel.
Under this circumstance, AP should perform CAC itself, and the background
chain could also perform CAC simultaneously.

After these annoying message here the build. As usual, please let me know. Thanks for sharing info.

here:

10 Likes

Your notes are like gold! :1st_place_medal: The details are important and much appreciated.

Kudos on all your work that goes into these releases!

3 Likes