I can't speak for AX3600 specifically other than to say that I have 300 down and run SQM and I am able to get full speed with it enabled. In my experience with my old WRT1900AC, SQM is CPU Bound, and I could never get any more than ~220Mbps down on the same link with it enabled.
You can bypass SQM on the downlink by setting the bandwidth to 0 in the Luci UI. I feel like downstream SQM is likely to be completely unnecessary on a 1Gbps link and probably not too useful on the uplink either unless it's fractional bandwidth and heavily loaded.
If you have downstream bufferbloat and latency on such a large pipe you probably want to use tc directly to traffic shape and set buffer sizes. You can also set the default qdisc in SQM to fq_codel and pick the simple.qos and you'll end up with a tc config very similar to what's on lartc.org which provides a basic 3 tier (bulk/default/time sensitive) traffic config which will add some basic fair queuing and buffer adjustments at far less CPU usage. I suspect cake/SQM is probably overkill on a 1 Gig link.
Hi,
how it is going on with the PR?
If i am correct, we now have a solution for a single partition? Is this already in the robimarko branch? Or do we need some more testing?
What else do we need?
Thanks for the update @Ansuel@robimarko
This is a 1gig/300m fiber line with latest Robimarko image, no SQM no traffic shaping, some torrent seeding was going on, and a YT video was playing:
And this is the result with the server not even in the same country as I am. So this looks pretty fine. (Local speedtest gets 900+/320Mbits repeatedly).
Wired of course. I doubt SQM can do a better job on a wifi link compared to the internal scheduler of the radio which has realtime access to channel state information, utilization, interference, BF etc.
Doesnt the result depend on the connection / Internet type you are using?
When I fully load my coaxial cable Internet, I get a lot of bufferbloat.
With SQM enabled, it reduces the speeds to around 400 mbit and a even get a A+ grade results.
Of course I tested it on a PC wired.
I just thought the SoC / CPU of this device is pretty powerful for tasks like this.
Using FQ Codel and Simple QOS give me a worse Bufferbloat than Cake / Piece of Cake, with nearly no benefits in speeds.
I will try to use SQM only on upload, to check how the quality will be.
BTW: It is correct to use eth0 for SQM or should I use a different "adapter"?
And for me it looks like Packet Steering ads just a little bit of small ping/lag.
Of course it does. On DSL the large asymmetry or on DOCSIS the shared nature of the media (eg. overload), SQM can help quite a bit. Even on fiber, it can help if a ONT is badly designed, or the provider is not up their game in terms of configuration of PON QoS on the OLT and ONT (seen example to both). But it has nothing to do with Wifi. The wireless channel can change so quickly and dramatically, that the only option to push the channel to its maximum capacity is via the scheduler of the air interface (ath11k and the QCA firmware in this case). There is nothing SQM can do about this unless you want to loose quite a bit of bw in general.
cake/pice of cake also gives me the same results ... I am not looking for speed but bufferbloat ... note I am using mwan3 with loadbalancing... haven't seen any benefits with switching off ingress ... yes using eth0 (and on my case eth1 as I am using two wans)
Well, not yet. I contacted QCA, they asked some debug logs about the crash, I gave it to them, no response ever since (2+ weeks). I think I am going to ask again if they need anything or come up with anything. What we suspect with Robi is that they f*cked something up with 2.6+ about the specific FEM the AX6 has and no other 807x devices seems to have, as every other ipq807x device can run the latest 2.7 FW with some slight modifications, except the AX6. As other (ipq6000) devices does have exactly the same FEM, there is a small chance that QCA might fix this, but for how long would that take...
even with the correct tool you can't do anything with them... they are to analyze fw bugs but we don't have access to fw symbol so again useless...
btw afaik qdss trace can be analyzed with windows perf/debug tools...
Kvalo mentions on the bug that @robimarko raised https://lore.kernel.org/ath11k/877czn8c2n.fsf@kernel.org/T/#u this tool and that they will compare both propositions to fix this bug ... i honestly feel that at least @robi should have access to the fw symbols etc so at least we are on the same footing as QCA .... so much for opensource if this doesn't happen
from @kvalo on the link i shared above
"The solution we have been thinking internally would not use
MHI_CB_EE_SBL_MODE at all, it's not clear for me yet why the mode was
not needed in our solution. Maybe there are firmware modifications? I
think it's best that we submit our proposal as well, then we can then
compare implementations and see what is the best course of action.
But it looks that not all ath11k hardware and firmware releases support
this feature, we would need meta data information from the firmware to
detect it. I am working on adding firmware meta data support[1] to
ath11k, will post patches for that "soon"."
EDIT... between the lines even Qualcomm doesn't share everything with Kvalo !
it seems their focus / energy now is ath12k and another splurge of spaghethi that will result in the future " it's not clear for me yet" why we have done this way ... wouldn't been easier for cloudsource the testing and open it ! definetely I don't think there;s much ip on what they are doing unless hiding IP they stole! ... allegedly
firmware is just of a close door ... hiding beyond transparency. If they have lodged IP and have the rights surely anyone can defend it in a court of law anywhere ... why hiding it?
The wireless channel can change so quickly and dramatically, that the only option to push the channel to its maximum capacity is via the scheduler of the air interface (ath11k and the QCA firmware in this case). There is nothing SQM can do about this unless you want to loose quite a bit of bw in general.