Re: [Cake] Trouble with CAKE

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Thibaut <hacks@slashdirt.org> writes:

> Hi Toke,
>
>> On 14 Dec 2019, at 13:59, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> 
>> Thibaut <hacks@slashdirt.org> writes:
>> 
>>>> On 14 Dec 2019, at 13:09, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>> 
>>>>> On 14 Dec, 2019, at 1:59 pm, Thibaut <hacks@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 :)

-Toke