Thibaut <[email protected]> writes: > Hi Toke, > >> On 14 Dec 2019, at 13:59, Toke Høiland-Jørgensen <[email protected]> wrote: >> >> Thibaut <[email protected]> writes: >> >>>> On 14 Dec 2019, at 13:09, Jonathan Morton <[email protected]> wrote: >>>> >>>>> On 14 Dec, 2019, at 1:59 pm, Thibaut <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
