[Cake] Trouble with CAKE

Toke Høiland-Jørgensen toke at redhat.com
Sat Dec 14 16:35:12 EST 2019

Thibaut <hacks at slashdirt.org> writes:

> Hi Toke,
>> On 14 Dec 2019, at 13:59, Toke Høiland-Jørgensen <toke at redhat.com> wrote:
>> Thibaut <hacks at slashdirt.org> writes:
>>>> On 14 Dec 2019, at 13:09, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>>>> On 14 Dec, 2019, at 1:59 pm, Thibaut <hacks at slashdirt.org> wrote:
>>>>> I’m wondering if this could be an “use of uninitialized data” type of bug.
>>>> This is why I wouldn't keep working on an old kernel that's full of vendor patches.
>>> Forgive me for trying to use cake on a supported stable distro.
>>> All distros are full of vendor patches (OpenWRT is no exception). The
>>> subset of linux machines that use vanilla is ‘below measurable
>>> threshold’...
>> The Linux kernel development moves at a fairly rapid pace, and sadly
>> it's not practical to have fully supported backwards compatibility in a
>> community effort such as CAKE.
>> Now, this doesn't mean that we won't take patches to fix things for old
>> kernels; or even help with debugging on old versions, as you've already
>> seen in this thread. But the reality is unfortunately that the bulk of
>> this effort is going to have to be on the users running on those
>> kernels. I.e., you in this case. Such is open source: everyone scratches
>> their own itch and the end result is something that (mostly) works for
>> everyone :)
> I understand that, I’m familiar with the kernel development philosophy
> (I used to be a contributor in a previous life).
> I’m also familiar with the fact that most kernel hackers tend to
> assume that the people who use their code and report bugs will know
> said code like the back of their hand and will be capable to spot
> where to look for the cause of the behavior they’re seing and provide
> a patch without further ado.
> I hope you can see why this cannot be the case especially with
> something as delicate and complex as a traffic shaper :)
> That’s why I’m happy to debug as much as possible and possibly try to
> cook a patch if needed, but without a bit of help/feedback (and thus
> interest) from the authors, this is a lost cause.
> Meanwhile, I can add that not all traffic crawls to a grinding halt:
> speedtests and fluctuating traffic (such as, in the case of the
> buildbots, the upstreaming of the build stdio) appear to be mostly
> unaffected (I see sustained traffic at line speed every now and then,
> especially during very verbose build output).
> But for some reason, when the rsync of the build results begins, cake
> appears adamant (at least when it exposes the offending behavior) that
> it must be killed with extreme prejudice ;P
> Would that ring any bell?

Not really. A first step towards making progress with this could be a
packet dump of a TCP stream that is affected by the slowdown, vs one
that isn't. Preferably with before/after stats output from CAKE from
each of them. That way, hopefully it'll be possible to figure out *what*
is happening to make things crawl, which could ease the such for the why
of it afterwards :)


More information about the Cake mailing list