Is there any way to make SQM detect the download and upload speed automatically in real time without putting it manually ?
imagine if SQM can just take care of whatever speed you have in real time !
Like for example if you have 300down and 100up speed . And suddenly the speed goes down to 100down and 20up NO PROBLEM SQM get you covered!!! That will be the absolute end of the bufferbloat and the ping spikes!
Awesome! That will be absolutely a game changer! Specially for those using 3G/4G/5G connection! But is it possible? I think yes ....
Right now, no - nor within the foreseeable future.
--
In theory this could be possible, but would involve a lot of non-existing external orchestration - and I'm not so sure 3g/4g/5g users would appreciate a significant part of their allotted volume to be spent on regular automated speed tests (nor that you'd find that many resources to provide the corresponding servers to test against - no, the brutto link rate isn't sufficient).
Automatic capacity estimation based on traffic arriving at this
qdisc. This is most likely to be useful with cellular links, which
tend to change quality randomly. A bandwidth parameter can be used
in conjunction to specify an initial estimate. The shaper will
periodically be set to a bandwidth slightly below the estimated rate.
This estimator cannot estimate the bandwidth of links downstream of
itself.
never tried myself, there some topics on this. there are also some topics with some scripts to auto-rate ingress/egress but as @slh said will consume bandwidth so not ideal for mobile contracts.
The autorate-ingress option is something that cannot be used in the real world. I have tried it on a WiFi uplink that is capable of sometimes 30, sometimes 130 Mbps. Result: any large upload will cause the filter to quickly adapt to the downward traffic consisting entirely of ACKs. I.e. to something like 0.5 Mbps. And, because then the incoming packets will be perfectly timed with no bursts, the code (which relies on bursts to take speed measurements) will not even think about undoing the decisions. I.e. the link will stay shaped to 0.5 Mbps for tens of minutes.
I was going to submit my questions about the actual code to the mailing list (namely, why is "packet_interval > q->avg_packet_interval" the condition for estimating the link bandwidth) but never found time to do that.
As everybody else already explained, unfortunately not. Yes it would be sweet, but no it will not happen.
You can try to work around things by using proxies for speed/delay, like ICMP RTTs to selected hosts, like @dlakelan proposed (and implemented), but that really is just a proxy (not a bad one, but still a proxy) and has some issues with figuring out whether congestion affects the up, the down or both directions.
Just tossing this out there, but what if you know you have just seen 100MB come in in 10 seconds? You know that's 80Mbps download. What about devising a way to monitor ingress and egress traffic on a particular interface and dynamically updating the SQM parameters with that result?
This is not perfect, or even close, because for starters, let's say you download a file from a slow sever, even though you have a gigabit internet connection, the algorithm will assume you have a slow connection and shape everything accordingly. The other problem is that OpenWrt is so stable that eventually the numbers you would be working with will become so large that your router will run out of memory to store them for the computations
But all jokes aside, has as anyone tried anything like this? It would be simple to put together a proof of concept and have a play.
Edit: After giving it some more thought, this approach seems like it could either be self-limiting (because it may not able to adapt when the real link becomes faster), or it could require "sampling periods" where the SQM is turned off so that it can see the real rate at which traffic is flowing, which would would be annoying for users.
That approach is problematic, as you never know why an arbitrary traffic load is throttling. So e.g. you are just watching a UHD movie with for the sake of our argument a constant bit rate codec and packet pacing at ~25Mbps. With your proposal SQM would throttle the link hard to ~25 Mbps in spite of the fact that the observed traffic limit was simply caused by the traffic source not seeking to reach the link's capacity... But you realized that yourself already...
I think they do. They might exempt that traffic from the current SQM instance or stop that. But they also take great care in making sure they have a reliable and robust measurement infrastructure for the actual speedtest.
