@rosbeef did you try a higher delay_thr_mr?
@Monochrome did you get CAKE to work with your VPN pbr setup?
Sorry i had no time, Spring ask me to work for autonomy in the garden. I will try to do the test on collapsed hours, to better adjust the parameters when i require the most sqm cake autorate. so in 2 hours more or less 
then tomorow i will test with same values during uncollapsed hours
yes i did try to increase delay_thr_mr that increase my bandwith but increase my jitter too.
for next datas delay_thr_mr is to default.
here it is : https://pastebin.com/AdYtYqx3
i put bufferbloat refractory period: 400000 us.
but "tells me expected time to overwrite samples in bufferbloat detection window is: 400000 us."
then : "Consider increasing bufferbloat refractory period or decreasing bufferbloat detection window."
should bufferbloat refractory period be sctrictly superior to bufferbloat detection window ?
and delay_thr_ms is set to 75
bufferbloat_detection_window to 8
bufferbloat_detection_thr to 4
@rosbeef I'm really not sure what to make of the plot of your most recent data. It looks better to me. This seems like a challenging case because of the very fast rate of change of your capacity.
Any thoughts @moeller0?
This is with:
delta_delay_tyr_ms=75
# bufferbloat is detected when (bufferbloat_detection_thr) samples
# out of the last (bufferbloat detection window) samples are delayed
bufferbloat_detection_window=8 # number of samples to retain in detection window
bufferbloat_detection_thr=4 # number of delayed samples for bufferbloat detectio
This for me is a point of interest here:
I presume this is supposed to be during a saturating download but the connection capacity dropped significantly down from around 7Mbit/s to more like 3Mbit/s. cake-autorate interpreted this as low load and so decayed slightly from 7534 to 7000 and held the CAKE rate during decay refractory period, and it was not until the bufferbloat that cake-autorate realised that the capacity had significantly dropped.
This is all captured here:
1661989888 6586 160 94 15 [1661989888.355142] 200.28.0.254 22 23536 58200 34698 76657 0 dl_high ul_low 7030 1040
1661989888 6586 160 93 15 [1661989888.442606] 200.29.48.201 26 36594 97100 60566 76655 0 dl_high ul_low 7100 1040
1661989888 6586 160 92 15 [1661989888.492804] 200.28.11.238 24 35578 42500 6928 76653 0 dl_high ul_low 7171 1040
1661989889 6586 160 91 15 [1661989888.496148] 190.82.63.254 25 60253 90500 30277 76651 0 dl_high ul_low 7242 1040
1661989889 6640 153 91 14 [1661989888.529433] 200.28.0.254 23 23543 31200 7664 76649 0 dl_high ul_low 7314 1040
1661989889 6640 153 90 14 [1661989888.589389] 200.29.48.201 27 36600 43300 6706 76647 0 dl_high ul_low 7387 1040
1661989889 6640 153 89 14 [1661989888.681799] 190.82.63.254 26 60267 74900 14647 76645 0 dl_high ul_low 7460 1040
1661989889 6640 153 89 14 [1661989888.692371] 200.28.11.238 25 35583 41100 5522 76643 0 dl_high ul_low 7534 1050
1661989889 2720 58 36 5 [1661989888.775616] 200.28.0.254 24 23594 74900 51357 76627 0 dl_low ul_low 7000 1050
1661989889 2720 58 38 5 [1661989888.783369] 200.29.48.201 28 35700 35600 -1000 76642 0 dl_low ul_low 7000 1050
1661989889 2720 58 38 5 [1661989888.884284] 190.82.63.254 27 60283 77200 16933 76642 0 dl_low ul_low 7000 1050
1661989889 2720 58 38 5 [1661989888.908925] 200.28.11.238 26 35602 55100 19517 76642 0 dl_low ul_low 7000 1050
1661989889 2843 63 40 6 [1661989888.923839] 200.28.0.254 25 23419 23400 -194 76642 0 dl_low ul_low 7000 1050
1661989889 2843 63 40 6 [1661989889.005306] 200.29.48.201 29 35721 57500 21800 76642 0 dl_low ul_low 7000 1050
1661989889 2843 63 40 6 [1661989889.090737] 200.28.11.238 27 35603 37100 1498 76642 0 dl_low ul_low 7000 1050
1661989889 3082 77 44 7 [1661989889.152769] 200.28.0.254 26 23448 53400 29981 76642 0 dl_low ul_low 7000 1050
1661989889 3082 77 44 7 [1661989889.192002] 200.29.48.201 30 35727 42700 6979 76642 0 dl_low ul_low 7000 1050
1661989889 3082 77 44 7 [1661989889.277705] 190.82.63.254 29 60291 69200 8917 76642 0 dl_low ul_low 7000 1050
1661989889 3123 33 44 3 [1661989889.342587] 200.28.11.238 28 35654 86800 51197 76642 0 dl_low ul_idle 7000 1050
1661989889 3123 33 44 3 [1661989889.343593] 200.28.0.254 27 23464 39800 16352 76642 0 dl_low ul_idle 7000 1050
1661989889 3123 33 44 3 [1661989889.389324] 200.29.48.201 31 35732 40900 5173 76642 0 dl_low ul_idle 7000 1050
1661989889 3123 33 44 3 [1661989889.478639] 190.82.63.254 30 60298 68200 7909 76642 0 dl_low ul_idle 7000 1050
1661989889 3123 33 44 3 [1661989889.489391] 200.28.11.238 29 35425 35400 -254 76642 0 dl_low ul_idle 7000 1050
1661989890 3369 72 48 6 [1661989889.559068] 200.28.0.254 28 23497 56900 33436 76642 0 dl_low ul_low 7000 1050
1661989890 3369 72 48 6 [1661989889.595056] 200.29.48.201 32 35740 43800 8068 76642 0 dl_low ul_low 7000 1050
1661989890 3369 72 48 6 [1661989889.687423] 190.82.63.254 31 60315 77400 17102 76642 0 dl_low ul_low 7000 1050
1661989890 3369 72 48 6 [1661989889.712039] 200.28.11.238 30 35444 54600 19175 76642 0 dl_low ul_low 7000 1060
1661989890 3185 43 45 4 [1661989889.746701] 200.28.0.254 29 23518 44900 21403 76629 0 dl_low ul_idle 7000 1060
1661989890 3185 43 45 4 [1661989889.788249] 200.29.48.201 33 35743 38800 3060 76629 0 dl_low ul_idle 7000 1060
1661989890 3185 43 45 4 [1661989889.877807] 190.82.63.254 32 60321 66600 6285 76629 0 dl_low ul_idle 7000 1060
1661989890 3185 43 45 4 [1661989889.890182] 200.28.11.238 31 34864 34800 -644 76629 0 dl_low ul_idle 7000 1060
1661989890 4394 82 62 7 [1661989890.078676] 200.28.0.254 30 23666 172000 148482 76629 1 dl_low ul_low 7000 1060
1661989890 4394 82 62 7 [1661989890.078774] 200.29.48.201 34 35831 124000 88257 76629 2 dl_low ul_low 7000 1060
1661989890 4394 82 62 7 [1661989890.095319] 190.82.63.254 33 60344 84100 23779 76629 2 dl_low ul_low 7000 1060
1661989890 4394 82 62 7 [1661989890.100425] 200.28.11.238 32 34871 42800 7936 76629 2 dl_low ul_low 7000 1060
1661989890 2613 65 37 6 [1661989890.148408] 200.28.0.254 31 23685 43500 19834 76629 2 dl_low ul_low 7000 1060
1661989890 3516 122 50 11 [1661989890.337043] 200.29.48.201 35 35979 184000 148169 76629 3 dl_low ul_low 7000 1060
1661989890 3516 122 50 11 [1661989890.344090] 190.82.63.254 34 60412 129000 68656 76629 3 dl_low ul_low 7000 1060
1661989890 3516 122 50 11 [1661989890.344187] 200.28.11.238 33 34921 85600 50729 76629 3 dl_low ul_low 7000 1060
1661989890 3516 122 50 11 [1661989890.357799] 200.28.0.254 32 23714 53500 29815 76629 2 dl_low ul_low 7000 1060
1661989891 3264 147 46 13 [1661989890.601250] 200.29.48.201 36 36189 246000 210021 76629 2 dl_low ul_low 7000 1060
1661989891 3264 147 46 13 [1661989890.601326] 190.82.63.254 35 60534 183000 122588 76629 3 dl_low ul_low 7000 1060
1661989891 3264 147 46 13 [1661989890.602614] 200.28.11.238 34 35025 139000 104079 76629 4 dl_low_bb ul_low_bb 2937 1000
1661989891 3264 147 111 14 [1661989890.602674] 200.28.0.254 33 23784 94200 70486 77010 4 dl_high_bb ul_low_bb 2937 1000
1661989891 3264 147 111 14 [1661989890.611910] 200.29.48.201 37 36205 53000 16811 77010 3 dl_high ul_low 2937 1000
Perhaps @rosbeef should reduce the decay_refractory_period_ms from the default 1000ms to 300ms as follows:
decay_refractory_period_ms=300 # (milliseconds)
Hey, thank you for this project and starting a new thread. I had no idea this project existed until I saw the new thread and looked over the previous 3000+ posts.
I'm wondering what people's experience has been like on cable modems? I did some searching on the previous 3000+ posts and it looks like most users are using this with 4G/hotspots. So I'm looking for feedback from folks who may have tried it with cable modems (specifically Comcast/Xfinity in the US), does it help when your speed changes at different hours of the day because of the traffic in your neighborhood?
I'm currently using DSL/FTTN so the speed is consistent, but occasionally I think about going to Xfinity because of different pricing & TV options. If adaptive SQM can help provide consistent performance then I'd give it more consideration.
1 Like
Better and not.
Multirate Video tend to go to higher resolutions but stuck then load smaller resolution due to saturation then tend to higher ... This night i do a new test with your decay to 300
Hi, I have been following the "historical" thread with great interest. I am on a VDSL2 line which has a severe bufferbloat issue (200+ms on upload). I would be grateful if the experts on this thread could help understand one point. RFC8289 is very specific that CoDel is "parameter-less" which would imply no need for specifiying the available bandwidth at all. CAKE (which I believe is a descendent of CoDel) depends on the available bandwidth being specified. What important detail am I missing? Thank you.
You did not miss anything. fq_codel and cake at their heart are active queue management solutions with flow queueing schedulers. However to actually make sure the AQM and scheduler do something they need to see queued up data. If you connect your DSL modem via Gigabit ethernet to your router packets never accumulate in the router but in the modem. But the modem probably uses over-sized and under-managed buffers, so what to do?
The solution was to use a traffic shaper like HTB or HFSC to move the bottleneck from the modem's DSL link to the link between router and modem, which is set to below the true achievable dsl rate. This way now the queue build up happens in the router where fq_codel can do its "magic".
When cake was designed an optional traffic shaper was integrated into the qdisc so that users would not have to play with multiple qdiscs at the same time. If you want to use cake without the shaper use unlimited instead of e.g. bandwidth 1000kbps.
On your DSL link you likely need a traffic shaper, often on DSL a well configured static shaper works well, but autorate should also work well.
3 Likes
Thank you so much for explaining so well. The gigabit link between the router and the modem was the missing piece of the puzzle! Of course the router (with CAKE) has no idea that there is a queue building up on the modem.
So if I understand correctly, the bandwidth constraints are configured on the "traffic shapper" component of the solution, and not the AQM component (which presumably makes decisions based on how long packets spend sitting in the queue).
To take this thought one step further. If the router had an integrated DSL modem, would there be a need for a traffic shaper at all? Perhaps the AQM on its own be able to eliminate bufferbloat?
Thank you again.
Unfortunatelly an integrated modem is not enough, the modem would need to be able to tell cake when to stop sending data into the modems's queue. Linux does something called byte queue limits (BQL) for (some) ethernet drivers, but the lantiq dsl modems do not support that.
That said this way you could control the dsl link, but sometimes the real problem is the DSLAM's uplink and not the dsl link itself.
2 Likes
Just a big thank you to you Lynx,i hope that my bad connection is a good for your project
Here is the data of the night with
:https://pastebin.com/1DJAvGU7
Could you explain me which column represent what
time stamp ? RTT ? ? ? reflector ? ? ? ? ? ? dl_cake_state ul_cake_state dl_rateul_rate
1662078274.546246 6 13 0 0 [1662078274.542686] 200.29.48.201 1 36768 46000 9241 75428 0 dl_idle ul_idle 7000 7000
1 Like
I think that it would help if you only change one thing at a time. Seems to me that you also changed the base bandwidth to 7Mbit/s, which I think in your situation does not make sense because of the quality of your connection:
Your base should probably be more like 1Mbit/s or 2Mbit/s because otherwise you will get huge bufferbloat on step loads.
The bandwidth / RTT is not fantastic. What are your LTE stats? Can you improve your LTE stats by changing the position of your LTE modem or purchasing and installing an external antenna? It might be worth trying to work on that aspect before optimizing cake-autorate here to make sure we are working with the best you can get first.
To give an example, my Huawei B818-263 works best when on its side, face down, lying against the wall underneath the window in our office. If you were to look at it you would say that makes little sense, but in this location and orientation I get excellent LTE stats and a good connection to my cell tower:
If you can get visibility of your LTE stats you can try to optimize the location and orientation of your LTE modem/antenna based on those and the transfer speeds (with CAKE off).
This nicely demonstrates that we humans have quite imprecise intuition about electromagnetic wave propagation outside of the visible light range... +1 for exploring and trying even extreme positions.
2 Likes
I just had an experience trying to help a friend get WiFi out to his garage. Whereas we live in an old 1840 stone building with metre thick walls and WiFi gets through that no problem with our 3x RT3200's, our friend has a modern build and whatever is in those walls seems to stop WiFi dead. The only way we managed to get WiFi out of his house was to place an old BT router in the loft above the walls and above a layer of kingspan (metal coated insulating material in the roof). That way we got a signal outside and into his garage.
1 Like
Possibly a dense enough metal frame/mesh....
I would always try to run ethernet cable for stuff like that if possible and the put an AP into the garage, which might even allow to use power-over-ethernet so that AP can be shut down from the main house if desired. Then again sometimes reality is pesky in that things that are desirable are impossible or come at too high costs/side effects. Great that you found a solution!
I've been using my own perl implementation of cake-autorate on a Virgin Media cable connection in the UK for a couple of years now. I gradually improved it during that time based on the discussion in the old thread, and it works very well. My cable connection bandwidth varies significantly throughout the day, especially at peak times in the mornings and evenings.
I would expect @Lynx's implementation to work well for cable connections too. Our approaches are very similar, with the only significant difference being that mine measures upload and download latency separately, and adjusts upload and download bandwidth separately (like the Lua implementation).
3 Likes
Thank you for sharing. I'm eager to give this a shot.
1 Like
You should - @tievolu been well ahead in this game and is like me hugely motivated to making constant fixes and tweaks to make things work well. @tievolu are you tempted to release it all and have @richb-hanover-priv link in your code at the top? Would be fun to have another solution against which users can compare results.
1 Like
@tievolu - If you post a link to your repo, I will add it to the message that begins this topic.
Just as a note, I think that the lua approach was mostly developed/tested on DOCSIS/cable links, it might be what you are looking for (however I think installing that is not as easy as everybody would like, as it requires a patch that has not made it into OpenWrt yet).
1 Like