CAKE w/ Adaptive Bandwidth [August 2022 to March 2024]

@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 :wink:

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 :wink:

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:

image

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