Is it possible to LEDE to auto-adjust download-upload rate?

As title says is it possible somehow LEDE to auto configure download and upload bandwidth?
SQM settings is a "static" fix because during day ISP's change the bandwidth which is available so previous settings doesn't work anymore and must change again..and again..and again the settings.

well, if you have LEDE as the edge box in your network (no dsl/cable modem
between you and the ISP), then you don't need to have sqm on the outbound leg,
fq_codel will do the job for you.

But if you are not running LEDE on the bottleneck router, then you need to
artificially limit throughput to something below the bottleneck. The problem is
that since you are not the device at the bottleneck, you don't have a way of
knowing what the rate really is.

And since you are never running on the ISP side of the bottleneck, you are
limitedto guessing what it is.

so no, there really isn't a reasonable way to auto-detect what the right values
should be.

How does IQrouter doing this?

Based on their FAQ page, it sounds to me that it runs a speed test once per day.
Probably shuts off SQM, runs a speed test, tweak speed limits and re-enables SQM.

http://evenroute.com/faq

IQrouter’s intelligent decision-making process first characterizes your line, either by reading the actual line metrics from the modem, or by running actual throughput tests, it then sets all the relevant traffic management properties, namely the numerous Quality of Service (QoS) and Smart Queue Management (SQM) parameters and then tests those parameters to make sure your Internet Quality grade is an A. It then sets up a schedule to monitor and tune those parameters as needed over time.
...
Let the daily monitoring process detect your line speed has changed, which will adjust the Quality settings as necessary.

by being the actual gateway. It has the modem in it, so it can see exactly what
bits are being passed and query the modem for it's configuration.

I slightly overstated things when I said that you can't detect the inbound rate.
If you are using a signaling type where the modem knows the bitrate, you can
read that from the modem

David Lang

It does it all the time with "Quality Schedule Monitoring" not one time per day...
It has "Router-based Speed test" .."Line tracking" see at techspecs it is a router only.
Configuring simillar like my set up....modem/router in "bridge" mode to act as modem.....and my tpliink with Lede.
Quick installation...

Somehow we can do this and in LEDE...any thoughts?

It does it all the time with "Quality Schedule Monitoring" not one time per day...
It has "Router-based Speed test" .."Line tracking" see at techspecs it is a router only.
Configuring simillar like my set up....modem/router in "bridge" mode to act as modem.....and my tpliink with Lede.
Quick installation...

Somehow we can do this and in LEDE...any thoughts?

Sure, if you happen to be running one of the very few DSL routers. Just have a
script that reads the modem details from /sys and adjust the SQM settings.

David Lang

Something to read and learn how to do that?

I would start looking is /sys (probably /sys/devices) to find your modem device
and see what parameters your specific driver provides you

As far as I can see @Knomax's problem is not getting the sync rate of his ADSL modem, but the fact that his ISP's internal network has periods of internal congestion. That is not really in sqm scripts scope. As far as I know gargoyle offers something for ingress called ACC active congestion control, where it actively measures ping delays against a reference host and adjusts shaper bandwidth the minimize the latency under load increase. cake's autorate_ingress might also alleviate his situation a bit, I seem to recall that Jonathan uses it on mobile links to some success. My question is more will setting the shaper bandwidth lower during congestion periods really improve the situation, but that can be easily tested by just setting the shaper to 50% during a perceived congestion period and running say dslreport's speedtest...

Best Regards

My really problem is that in upload i can't reduce bufferbloat under 20-40ms...dsl reports test.
Every settings that i use cake,fq_codel....every sqm script....additional parameters in advanced settings......just fails......in download i figure out to not increase above 3ms in every test....in upload is the problem.

With only 1024Kbps a typical packet will take (32538)/(1024*1000) = 0.01325 seconds or 13 milliseconds, so serialization delay alone will make a latency under load increase by 13ms very likely. So 20ms does not seem to bad, that said, let's see whether we can decrease this a bit further...

Best Regards

How you calculate this???yes usually i have 13milliseconds in upload.
I put my modem/router..in bridge mode and Lede make the PPPoE connection....trial and error...i think.

I am thinking how if it possible to "delay" a little the packets in upload to have the time to "pass" out in internet and not be congested...sorry for non technical language.I said it as i understand this.

So assuming a MTU of 1500 Bytes and your per packet overhead of 26 (this is the value from the ATM_overhead_detector, right?), we end up with 1526Bytes that need to be transferred. Due to the fact that ATM uses cells of 53 bytes for every 48 bytes of user data we multiply 1526 * 53/48 = 1684.95833333, but since each user packet is encapsulted in an integer number of ATM cells we actually need to do ceil(1526/48)53 = 1696 (1526/48 = 31.7916666667, so our hypotetical packet requires the next integer number cells, or 32 in our case). This explains the 3253, hopefully.

Now this is 3253 = 1696 Bytes, so we multiply by 8 to get the bits 32538 = 13568 Bits/packet.
Since your uplink is runing at 1024 KBits/second we multiply by 1000 to get 1024
1000 = 1024000 Bits/second.

Then (32538)Bits / (1024*1000 Bits/second) = 0.01325 seconds to transfer that packet. So a single full-sized packet ahead of your latency critical packet will already increase the latency by 13ms. In the light of that a latency increase under load of around 20 to 40 ms seems somewhat acceptable to me, we are only talking about 2-3 packets...

This is not a bad idea, I would actually instantiate sqm not on eth0 but on pppoe-wan in that case. That way sqm will never drop PPPoE LCP packets...

Well that is what sqm script attempts, just with slow links we need to allow at least one packet ahead of us (think you just send a full sized packet to the modem, now the next chance to send a packet is ~13ms later independent on how important the packet is that comes in next; actually all the re-ordering to account for different priorities only works if we have multiple packets to choose from).

Hope that helps

Thank you very much.