Im going to retest the new build in the next hour and update the post with little bit more consistent results 
@pesa1234 Here are some updated tests on the latest build:
WED Disabled with 8ms target and 80ms interval and AQL low: 1500, high: 5000:
WED Disabled with 8ms target and 80ms interval and AQL low: 1500, high: 1500:
Waht do you feel? With wed enabled?
So, resuming the long spam post with bufferbloat results from different devices and browsers:
On iPhone with target of 5ms and interval 50ms im getting consistent A+
On MacBook 2015 with:
1300.0 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 3, Short GI
1170.0 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 3
In Safari A-B
in Chrome consistent A.
With a target of 8 ms and 80 ms interval:
Iphone: consistent A
Mackbook Safari: B-A
Macbook Chrome: consistent A
1 Like
This is interesting, check out this data:
WED Disabled with 8ms target and 80ms interval and AQL low: 1500, high: 5000:
WED Enabled with 8ms target and 80ms interval and AQL low: 1500, high: 5000:
I didn't catch all the tweaks you made since yesterday's build, but somehow with WED enabled today, the latency is still very equivalent on the individual download / upload tests. There are a lot more excursions into higher latency during the combined test, but that seems to trend with the spikes in download latency.
This is really interesting and I'm still processing all the factors here.
Did someone try the new background radar feature?
Me, I get a signal of radar every day and I didn't get any issues for now. If you live in a zone with some radar signals it is useful.
This is my own opinion.
Before activate it sometimes 5ghz radio goes off for 30 minutes...
1 Like
Good you confirm what I see. So we need to wait other user experience.
Thanks a lot for your test and suggestions.
2 Likes
Thanks!
I'll start using it aswell since I'm near an airport so you get some more testing on this
1 Like
Just flashed!
So I'm back to the usual suspects: HFO/SFO, WED and no SQM.
Laptop is great as usual
S23 is showing improvements!
OnePlus 8T
iPhone 12
It doesn't make sense to me but slower clients (80mhz) suffer higher latencies.
We're making progress nonetheless! Thank you pesa1234 for the effort.
3 Likes
Maybe the "slow" devices when are closer to their maximum speed start to increase the ping... If you disable wed do you see an improvement?
One more question...
Do you have the same issue with std openwrt build?
Thanks again
@auanasgheps This is a critical piece of info. If you haven't yet disabled WED and tried your OnePlus 8T and iPhone 12 bufferbloat tests, that definitely is the next thing to try.
1 Like
With the second test build, I’m now getting A’s with my iPhone 13 mini with or without WED and can’t tell much of a difference with it on or off.
WED on: https://www.waveform.com/tools/bufferbloat?test-id=c4fe892a-6a69-4179-9eee-937cc87f25c0
WED off: https://www.waveform.com/tools/bufferbloat?test-id=df6167f9-7f73-4e7f-918a-297566d01328
Not using SQM. HFO and SFO. Great progress!
4 Likes
Allright, tonight or tomorrow I should have some time to test, this time without WED!
I will also try to test with the standard openwrt build.
Few days ago I briefly tested the official Gl.Inet OpenWRT 24.x. It's a beta, came out few days ago. It had WED enabled by default. When I disabled it, I saw very good performance (+20 ms download, +19 upload. Score A) but I only tested one device because I didn't had much time.
My goal is to get more tests out of these builds.
I'd be happy to reach consistently "A" score / less than 30ms with the most performance (without SQM).
2 Likes
Disabled WED on the latest build:
S23
OnePlus 8T
Laptop
iPhone 12
When testing with fast clients, the overall CPU usage reaches 50%, but... hey, I'm getting an A with all clients, I'm happy! Results are super consistent.
Honestly I don't think I can ask for more, unless somebody in the future finds a way to improve WED.
Also, I don't think is worth enabling SQM since these latencies are pretty good.
Is there anything else that you want me to test or experiment?
Also, I'd like to offer a beer to Pesa for his work, can you send me your PayPal account?
5 Likes
Thanks, no need a beer it is a pleasure!
So, maybe WED in the next release will be off...
7 Likes
This is awesome feedback and progress! I'm curious... outside of benchmarks, how is the overall feel as you're just using your devices? Do you notice any difference in browsing speed, whether good or bad?
I can't.
I'm still running my old Asus RT86U as main router, and I plug the MT6000 just for the testing I'm reporting here.
The Asus has been a great warrior but it's officially out of support.
I am strongly focused on the raw numbers but in reality those performance benefits will be almost non existent. We all know this, but I like to take things to their limit just because, maybe, in the future, I might use them.
The experience with the Asus was pretty good (bufferbloat is usually B or A, no QoS) and I'm sure will be with this router too, with the benefit of increased bandwith. If I was upgrading from a shitty ISP box maybe I would have seen a difference, but after a certain treshold you can't really feel the improvements!
I feel like we're chasing different targets here, you and I. Correct me where I'm wrong, but I feel you are chasing maximum possible bandwidth. Conversely, I am chasing lowest possible latency. In wireless world (at least with present hardware), the two are almost diametrically opposed. 
Couldn't disagree more Just depends on one's definitions of "performance" and "benefits". Allow me let me explain my viewpoint...
For example, when considering the standard use-case of a user browsing the internet in general, DNS queries are in the hundreds (or potentially thousands) in a typical browsing session. In order to start making use of whatever bandwidth is available to the user, there first must exist the translation of a FQDN to an IP address--hence the DNS lookup.
Let's say a user has a symmetric gigabit ISP connection. Assuming best possible conditions, that's ~940Mbps after overhead. That translates to ~117.5 MB/s. Amazon's US homepage for me shows to be ~10 MB in content. So in theory, if DNS is taken out of the equation (and assuming Amazon's edge servers can shoot data to the user at ~940Mbps) then the page's content could be acquired to the browser in ~100ms.
But instead, the user will generally see that it takes more like 3-4 seconds (even at gigabit speed) for the content to come down. Some of that time is browser rendering speed, but a bulk of that time is due to DNS lookups. Let's just say Amazon's homepage has references to 20 unique FQDNs (this is just for example sake--it is likely much higher than that). If, due to poor latency in the wireless stack, there is an extra (arbitrary pick here) 40ms+ of "bloat" at the wifi-level, then that is going to have a significant impact on the time it takes for the user's machine to tell its DNS server that it needs a record, then the DNS server has to forward that upstream, wait for the response, then send the reply back to the client with another 40ms+ of latency in the wireless stack. The math in that case quickly adds up to a lot of extra latency in just trying to get IP addresses for which to go make use of raw bandwidth.
In the above scenario, the user's perception is likely going to be along the lines of, "I thought gigabit was supposed to be fast! What the heck is going on here?!" But if you start whittling down the latency (i.e. bloat) in the wireless stack, then the user starts getting to use that raw bandwidth faster because things like DNS lookups don't have nearly the same overhead in terms of bloat. So by shaving milliseconds off the wireless stack, a DNS query that might have taken 40ms + 40ms + ~20ms of time for DNS upstream resolution = 100ms could now be more like 5ms + 5ms + 20ms of time for the DNS query = 30ms.
That said, shaving off even a millisecond in one direction of a packet's RTT in the wireless stack is where my mind is at these days because the effects are real. (Don't get me started on how it can even open the doors to gaming over wireless 
)
7 Likes
Honestly speaking, with such a powerful router and all the recent enhancements (and buzzword) around WiFi, I was expecting great latency, along the very high speed I am actually obtaining.
But it's okay.
Yes, I am trying to get the most speed, then lower latencies. But I'm also confident that WED will be improved in the future, after all it's a pretty new platform and just in the recent two months we've seen great improvements in WiFi performance with OpenWRT and the opensource driver.
Now that 6.6.x kernel is merged in main, what is the difference between Pesa's build and the official build, aside the included packages? Are there some optimizations that aren't in main?