No worries about no bridge mode. You can still avoid double nat. See here:
2 Likes
I just factory reset my Zyxel OpenWRT router and connected the LTE-router (Archer MR200) to from its LAN port to the WAN port of the Zyxel, and it works very well. The only problem is that the Zyxel router the IP adress 192.168.0.106 (I guess it was assigned by the LTE-router) Where as the LTE-router has the IP: 192.168.0.1
(btw thank you for the guide @Lynx )
I wanted to change the LTE-router adress using the TP-link software but I am getting an error message: "IP address must be on the same subnet with the LAN IP" so I am not sure how to achieve different IP ranges.
But as long as it does not interfere with cake(-autorate) I think it is negligible in my situation. What would be my next steps to set up cake?
Follow this:
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
and then this:
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details
If you have questions I am happy to help with specifics. This would only be useful to get the base cake configuration roughly correct, and the next step would be to set up cake-autorate and fine-tune it...
2 Likes
Yes it probably won't affect cake/cake-autorate, but I'd still take the time to make sure you get this right - if a job is worth doing it is worth doing well. If necessary feel free to create a new separate thread about it to get help on it. I think the linked thread should give enough information to get it right.
Otherwise, yes keep posting on this thread and we'll help to get you up and running.
1 Like
I'm looking to try this out on my device and i have a few queries.
In the installation instructions it says to setup and install SQM and the Luci app and configure it as per normal
I'm a little confused by that as it seems the config parameters are setup in config.primary.sh and all entered settings from the luci page will be ignored such as interface and ingress and egress and link layer adaption.
Does the autorate script just on the fly patch the cake settings for a running instance or something?
If so can it not workout and obtain a running cake instance automatically and attach to it f the user should wish?
Also my 4g setup I'm using QMI and it dynamically creates IPV4 and IPV6 interfaces on startup do I'm guessing I configure the parent interface wwan as the dl_if and ul_if?
Are there plans to migrate to the normal /etc/config structure and configurable by UCI?
It would be great if this was included in the SQM package in master and have integration of the config parameters from the luci app.
Easy, cake-autorate operates by selectively changing the bandwidth setting of an operational cake instance without changing any of the other parameters... but that is why you need a way to configure the "base" cake instances appropriately... (sqm and alterntives like @Lynx's script and qosify all include hotplug handling so when an interface dis/- and reappears cake will be configured with the initial config again, and autorate will then change the rates again).
Sort of, yes. Patch is not necessarily the right mental model, as tc includes a change action for exactly that purpose, but aside from nomenclature you are correct.
I wish... a given set up might contain more than two cake instances, and just from their names it is unclear which handles internet download and which internet upload traffic. Deducing what a users wishes is pretty hard... as users might wish different things at different times.
Not sure, it really depends on what you want... but if that works as expected than likely yes 
I defer to cake-autorate's primary author and maintainer @Lynx for this question. My guess is, probably not any time soon.
This I can answer, and it is currently unlikely to happen, these are somewhat different projects, and sqm-scripts is considerably more conservative (and rightly so, it aims to be a robust and reliable starting point). I would not rule that out completely for all eternity, but right now: unlikely.
There is an open issue for this on the GitHub repository here:
But I just don't feel very motivated to take the time to implement a sort of bridge between the OpenWrt config system and that in cake-autorate (which has to work for other platforms like Asus Merlin). It's just a config file that needs modifying for the initial setup.
Let us know if you need any help setting up and tailoring the config to your specific needs. cake-autorate is really best optimised for each specific use case, and with data from your connection we can help optimise it for your needs.
It would be nice if there was a way to edit the config via Luci and a way to build bundle it into an image.
currently it relies on users to hand edit config files and run commands from shell which is not so great for anyone that is not so technical.
Could this be just built into cake package it is not such a bad idea?
1 Like
+1. That is the only single reason I personally have not installed autorate yet.
Perhaps, it could also exist as a separate profile in luci under SQM-> cake-> autorate.
Respectfully, the way opensource works is, if you have an itch you go scratch it, and then if you are friendly you might share the results back with the community. So given that neither cake-autorate nor sqm-scripts have any appetite for doing what you seem to desire, maybe the most productive way forward is to roll up your sleeves and implement the desired integration, no?
2 Likes
@moeller0 it has been a while since I fielded any new ideas. I know Iâm in danger of retreading over old ground, but I started thinking about the rate of increase of shaper rate on high load and how one might go about optimising that. Then I wondered again about ways to have that dynamically adjusted.
And the thought occurred to me - might it not be an idea to scale the shaper rate increase in dependence upon how close we are to the delta delay threshold?
So rather than oscillate around the maximum there is more like a target latency on load and as that is approached the shaper rate increase is circa zero?
So when latency is circa baseline we increase shaper rate at maximum rate. Then when latency increases we scale until the latency hits the delta delay threshold and then the shaper rate is increased no further?
There may be issues with this and it may not fit in with our other control aspects, but wondering if there might be some mileage in something along these lines.
Maybe just try it out? The thing to keep in mind though is (even if er stick to only doing this when there is some organic load) that we could end up in a cycle of:
- low delay (enough load to engage) -> big increase of shaper rate
- senders take a while to ramp up, but then either overshoot (like slow starts typical double of the real achievable rate)
- high delay (and high load) -> big decrease of shaper rate
-> rinse and repeat.
So this might lead to oscillations/resonance which could be annoying... That is what the idea of keeping the increases slower than the decreases is intended to deal with, to dampen any oscillations and avoid resonances. But I see no reason why not to actually try this out, and the oscillation concerns might be addresses with keeping the increase factor lower than the equivalent decrease factor for the rate reductions.
Hopefully this helps expand on things a little. Thinking about this further, we sort of already do something like this on the punishment side of things:
# rate adjustment parameters
# shaper rate is adjusted by a maximum of shaper_rate_max_adjust_down_bufferbloat on detection of bufferbloat
# and this is scaled by the average delta owd / average owd delta threshold
# otherwise shaper rate is adjusted up on load high, and down on load idle or low
shaper_rate_min_adjust_down_bufferbloat=0.99 # how rapidly to reduce shaper rate upon detection of bufferbloat (min reduction)
shaper_rate_max_adjust_down_bufferbloat=0.75 # how rapidly to reduce shaper rate upon detection of bufferbloat (max reduction)
shaper_rate_adjust_up_load_high=1.04 # how rapidly to increase shaper rate upon high load detected
shaper_rate_adjust_down_load_low=0.99 # how rapidly to return down to base shaper rate upon idle or low load detected
shaper_rate_adjust_up_load_low=1.01 # how rapidly to return up to base shaper rate upon idle or low load detected
Namely, in respect of the bufferbloat handling, we punish the shaper rate between 0.99 and 0.75 in dependence upon how the average OWD delta sits between the following two tresholds:
# owd delta threshold in ms is the extent of OWD increase to classify as a delay
# these are automatically adjusted based on maximum on the wire packet size
# (adjustment significant at sub 12Mbit/s rates, else negligible)
dl_owd_delta_thr_ms=30.0 # (milliseconds)
ul_owd_delta_thr_ms=30.0 # (milliseconds)
# average owd delta threshold in ms at which maximum adjust_down_bufferbloat is applied
dl_avg_owd_delta_thr_ms=60.0 # (milliseconds)
ul_avg_owd_delta_thr_ms=60.0 # (milliseconds)
So at present, where the average OWD delta sits around 30ms, then the factors are:
-
increase at 1.04 on high load once per achieved rates reading (every 200ms);
-
punish from 0.99 to 0.75 in dependence upon the extent of the overshoot.
Graphically, this looks like this:
Observe the big discontinuity between 1.04 and 0.99. Is this a good thing?
The question is whether it is still best to always simply increase at the 1.04 on high load once per achieved rates reading (every 200ms), or somehow scale that in dependence upon how close we are to either or both of the above thresholds.
Just thinking out loud, but what about something more like the following involving a crossover, with something like this:
That is, we actually still allow increase beyond owd_delta_thr_ms, but scale down and cross through zero as the delta reaches avg_owd_delta_thr_ms?
Something along these lines ameliorates the big discontinuity, and I'm wondering if it offers the prospect of reduced oscillations?
thank you and @Lynx so much. I set up cake(autorate) according to the guides you sent me (I did not understood all of it, but I managed to get a noticeable impact on bufferbloat. Now I wanted to ask if there is anything I could improve or test to get even better results.
Glad you got it to work! cake-autorate is extremely configurable - check the defaults.sh file for all the configuration options that one can override by placing a corresponding override entry in the config file. There is a trade-off between latency and bandwidth - you can reduce latency further but at the expense of reducing bandwidth or you can increase bandwidth to some degree at the expense of increasing latency. Itâs up to the user what sort of latency and bandwidth profile is desired.
2 Likes
One thing I struggle is I do not really know while listing services, sqm is always listed as "stopped" despite being active in LuCi. Any attempt to restart it fails, but in my comprehending It would be necesary that sqm is running, also to run the cake script properly.
Btw does one understand how the huge gap between my download vs. upload bufferbloat numbers comes from?
Some services donât show up as running when they should just as a consequence of their using the simpler, older non-procd format. In my mind âstoppedâ in that context means something like âthe start routine has completedâ.
For reasons @moeller0 can better explain, the ingress is harder to control than the egress. You could use tighter settings for download if you desire lower latency when loaded.
1 Like
The challenge with download shaping is that we sit on the wrong side of the bottleneck. On egress/upload if we set the shaper to 100% of the true capacity we still see the true bottleneck queue and can manage that decently. On ingress/download the problematic queue actually sits on the ISP side of things, so we need to create an artificial bottleneck on our side of the link, and if incoming traffic is too wide it will still 'back-spill' into the ISP-side buffers where we have no control over the queue. That is why download shaping is more approximate than upload shaping, and doubly so for autorate, as we have to find out say 90% of the true but unknown capacity, but our way of finding 100% is by exceeding it and then see latency increase, that is we tend to drive the ISP side queue to fill up to be able to detect the resulting latency increase as indicator we reached > 100% of capacity...,
Does this make sense to you?
3 Likes
Yes, seems to me to be a very clear explanation. Hopefully I wonât forget this.
Can we somehow leverage the fact that on download the buffer is remote in terms of our control?
So buffered packets are queued for delay_queue and then go over the last mile hop that is approx RTT/2, right? So for delayed packets can we estimate the size and/or delay incurred by the queue?
But that is what we are doing already, by splitting the measured delay into the presumably static path RTT/OWD (we call this baseline) and the variable part we call delta-delay, no?