Adaptive line speed QoS

G’day all,

I am researching the QoS packages.

What I have looked at there is a requirement for the line speed to be manually set as part of configuration by the user.

Is there a process or package that offers or is it development for the line speed to be checked prior to config?

User case here is for a consumer product where technical aptitude may cause more harm than good and where speed packs (increase speed) can be applied via an application to the service in real time.


i think you want:


There is this thread:

about adaptive rate setting scripts, but these still need user input for a number of parameters. once configured they will use active delay measurements to detect congestion and will adapt the shaper rates (within to-be-configured rate corridors) to counter act the congestion (that is a shaper rate reduction will move the bottleneck queue back onto the router running the script where a cometent traffic-shaper/AQM/scheduler combination will then tackle the congestion be signalling all flows to back-off a bit).

There are several speedtest* packages to run under OpenWrt but all of these come with the caveat that routers are not necessarily optimized for running applications so sourcing/sinking traffic on a router as a speedtest does will not be 100% reflective with how the router performs while routing packets (however a router that can traffic shape X Mbps should be well capabable of sourcing/sinking at least the same X Mbps without traffic-shaping, as traffic-shaping has a high CPU cost).

That sounds hard to achieve generically. That said, I believe evenroute does offer a commercial auto-tuning for traffic-shaping as part of their IQrouter line (based on OpenWrt) that might require no user settings at all (but then I never used their product so I might be wrong here).

*) But just running any speedtest is not guaranteed to give you the "correct" answer, as the speed measured in such a test depends on:
a) is the local node powerful enough to source/sink the traffic required to saturate the access link (it is that speed you need to measure)
b) is the remote node powerful enough to source/sink the traffic required to saturate the access link
c) does the rest of the network path have available capacity greater than the maximal capacity of the access link

Any of a-c can result in measurements indicating lower access capacity than truly available. Which IMHO means this needs some careful guidance, either by using your own measurement infrastructure on the remote side (allowing you to control for b)) or by having your end user look at the results and compare these to speedtest results against different target servers/services.
In theory this should be simple, but in practice there are quite some stumbling blocks.

@moeller0 and @ghoffman

Thanks so much for taking the time to review and reply.

I will review and continue along the journey.