[Cake] Trouble with CAKE

[Thibaut]

> Le 13 déc. 2019 à 23:40, Thibaut <hacks at slashdirt.org> a écrit :
> 
> 
> 
>> On 13 Dec 2019, at 23:39, Thibaut <hacks at slashdirt.org <mailto:hacks at slashdirt.org>> wrote:
>> 
>> Hi Jonathan,
>> 
>>> On 13 Dec 2019, at 15:02, Jonathan Morton <chromatix99 at gmail.com <mailto:chromatix99 at gmail.com>> wrote:
>>> 
>>>> On 13 Dec, 2019, at 3:43 pm, Thibaut <hacks at slashdirt.org <mailto:hacks at slashdirt.org>> wrote:
>>>> 
>>>> I've been using CAKE on my DSL-connected Linux router for the last few years, and it worked well until very recently. Two things happened:
>>>> 
>>>> 1) My ISP (French "Free") switched my DSLAM to native IPv6, which for the time being means that I had to revert to using their set-top-box (Freebox) instead of the VDSL2 model I was using in bridge mode until then (CAKE in "bridged-ptm ether-vlan" mode)
>>>> 2) I upgraded my router from 3.16 (Devuan Jessie) to 4.9 (Devuan ASCII)
>>>> 
>>>> Since then, no matter which setup I use, I cannot get CAKE to work as intended. Specifically, any long-standing best effort stream (such as a remote rsync) will be throttled to a near grinding halt even though there is no other significant traffic going on. Some random bursts can be seen (with iftop) but nothing ever gets close to half the maximum bandwidth. This is notably affecting the OpenWRT buildbots I'm hosting on this link.
>>> 
>>> Old kernels, including 4.9 series, tend to be more problematic than the latest ones.  If you can, I would recommend updating to a 5.x series kernel, in which Cake is an upstream feature.  I won't presume to guess how best to achieve that with your distro.
>> 
>> I’m now able to confirm this looks like a regression: I was able to retrieve and build the last known working version of CAKE on my router, and with an adjusted overhead of 48 atm (confirmed thanks to the help of Stephan), it works like a charm. Current HEAD doesn’t, with the exact same parameters.
> 
> I meant Sebastian, sorry. And this is old CAKE running on distro 4.9, for the sake of clarity

Culprit turned out to be easy to identify: it’s the current master HEAD.

Reverting 183b320 fixed the issue.

I hope this helps,
Thibaut

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20191214/269132ef/attachment-0001.html>