There absolutely are, yes. In fact, there are a lot of patches that @pesa1234 is continuing to tweak and tune based on the most recent wireless test results we’ve been talking through.
At the moment, going back to even mainline snapshot builds will feel like a step backwards in terms of wireless latency.
Pesa’s builds tagged mtk contain, by my count, around 47 additional mac80211 (Linux wireless subsystem) patches as compared to snapshot, many by mtk, and around 78 additional mt76 patches, again, many by mtk. So these builds are a lot more than a minor tweaked snapshot and contain a lot of work to integrate and tweak these patches for our kernel.
@pesa1234 Could you help me understand this better? If I'm set to 160mhz and channel 100, for example, would the 'Use specific channels' value be 100 to match the channel? Or is there more to it than that?
You shoul set the chanlist if you enable radar background examples if you are on 100... @160mhz
50 114 163... if you are in europe
I noticed this patch and it looks interesting. However, I know too little to understand it beyond some comments in the initial commit by cmonroe:
OWRT-8828: mt76: mt7915/mt7996: fix airtime spikes
apply patch from Mediatek to fetch STA airtime stats from MCU
apply a similar patch for MT7996 and include same logic from MT7915
should fix airtime spikes on all existing 11ax and 11be products
Not sure if it's applicable to this project but I thought I would drop it here anyway:
I guess another round of testing is coming soon... damn😛
Imported this and other two interesting patches... I'm testing. Thanks
I compiled next-r2.4.mtk at the latest commit fcef05c and am using it. As compared to the last builds I tried, most recently the pre-compiled next-r2.4.mtk.test2, my IPTV box no longer becomes unresponsive (requiring a restart), and two printers which were disconnecting and reconnecting, sometimes with deauth messages, are no longer doing so. I had previously tried all manner of advanced wireless settings to no avail. Perhaps this patch (mac80211: increase beacon loss) has something to do with it, or maybe it's something else. In any case, I will keep testing.
I have not tested latency yet.
This patch is to solve some unresponsive device, so maybe we catch it
upload 2024.06.09_r26646_6.6.32_next-r2.4.mtk.rc1
While I am enjoying this thread, a key thing to note IS "slower clients suffer higher latencies.". Ideally, if codel is working properly, this will be capped to about two txops max, 11-20 ms on the download, tops, somewhat dependent on the aql setting. On wifi with a fifo rather than codel, latencies can climb past seconds. (Starlink, before implementing fq_codel a few months ago, measured out at 7 seconds)
One test I use is capping the maximum bandwidth at the wifi layer to mcs0 or mcs1 using the iw tool.
A good test is also, with any one of these devices, through a wall, or at least 30 feet.
Here are some public details about starlink's progress here. A key statement that Elon made somewhere, was that, yes, indeed, "lower latencies mean operations start sooner". I have often tried to explain slow start in this way, and how all of our benchmarks are broken when compared to real traffic. Most traffic completes in well under 3 seconds. As much as I like the crusader test you are using, someday perhaps we can just zoom in on slow start more...
The last build is providing great results with WED disabled and no SQM.
The score is still "A" but I see an improvement in download latencies, especiall with my OnePlus 8T (80mhz client) which had a higher latency last time.
OP8T
S23
I also get a good result with this build. I even didn't get any strange disconnection issue on my very old android device...
Thanks again for you feedback
Can I verify, the install procedure for this build will be(I am running stock MT6000 firmware):
Another question, is it possible/safe to remove some unneeded packages like wireguard and adblock?
Yes, the procedure to update is right. Also if you want to come back to gl-inet version, flash from openwrt webui.
Regarding the unneeded packages, without configure they don't start or if you want to be more sure you can disable from LuCi (system-startup-disable) or from command line example: /etc/init.d/wireguard disable
Appreciate the work and time that you dedicated to these builds @pesa1234
In my case, with standard configuration the results are almost same (stable A score) with irq and wed off, but, turning off irq and turning on rps i have many more results with (A+)
Im playing warzone on wifi now and have really stable results.
Wow! This is SUPER news!
I'm very happy to see the results guys.
Without all off you we can not reach these result, so thank you all!
OT
I'm also playing warzone... please send me your id by pm and we play together some time if you want 
Woa, 500Mbits with A+ bufferbloat over WiFi... extremely impressive results.
My condolences on the game choice but that's fantastic (ok my friends play PUBG maybe not better) 
The dream would be to get the majority of these improvements upstream into OpenWrt main.