From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps.slashdirt.org (vps.slashdirt.org [144.91.108.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1B5A23B2A4 for ; Sat, 14 Dec 2019 09:04:56 -0500 (EST) Received: from tama.lan (unknown [37.165.135.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vps.slashdirt.org (Postfix) with ESMTPSA id 780F9600A9; Sat, 14 Dec 2019 15:04:54 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 vps.slashdirt.org 780F9600A9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=slashdirt.org; s=mail; t=1576332295; bh=x08QX5JHz61PdYtMRCDRVdXLeVNr81pi/8/RpVNYNZI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=tYneGR0QGnSfEUdnpAVmku5Cd71ydxxIIq9TvXWvvx7cSlhda+uJ9cPtrfxfkTGKt Kd6KXuW+cizKFjOgiNyUZLr5bWf18XEhpWlWHvbAQmdVlQ+Aw8mNTQOVsT6HnffhLc CRPkT1l4LDkiAGF/LhELpnbhXFbh1YXYMFBn2+hM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Thibaut In-Reply-To: <874ky3cbbc.fsf@toke.dk> Date: Sat, 14 Dec 2019 15:04:53 +0100 Cc: Jonathan Morton , Erik Taraldsen via Cake , Kevin 'ldir' Darbyshire-Bryant Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d359153abfc413b4f61c647437427d6@slashdirt.org> <8FC615C8-4885-4F0A-B2EE-934DC4E806E8@gmail.com> <6E9587F7-C208-4568-8429-AEBA9E694E24@slashdirt.org> <46DDBCAA-EC6C-492F-8448-DF85ABB4E1DB@slashdirt.org> <1507FAF0-8A13-48E1-8A36-0D352F4FDD00@gmail.com> <4E238145-37A2-45AC-B8BB-AD602C4D1044@darbyshire-bryant.me.uk> <55F31738-C935-4361-B11E-9E7CA657489F@slashdirt.org> <1632300D-56B8-4E9A-B4FD-C244D4F5AED6@gmail.com> <874ky3cbbc.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [Cake] Trouble with CAKE X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 14:04:56 -0000 Hi Toke, > On 14 Dec 2019, at 13:59, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Thibaut writes: >=20 >>> On 14 Dec 2019, at 13:09, Jonathan Morton = wrote: >>>=20 >>>> On 14 Dec, 2019, at 1:59 pm, Thibaut wrote: >>>>=20 >>>> I=E2=80=99m wondering if this could be an =E2=80=9Cuse of = uninitialized data=E2=80=9D type of bug. >>>=20 >>> This is why I wouldn't keep working on an old kernel that's full of = vendor patches. >>=20 >> Forgive me for trying to use cake on a supported stable distro. >>=20 >> All distros are full of vendor patches (OpenWRT is no exception). The >> subset of linux machines that use vanilla is =E2=80=98below = measurable >> threshold=E2=80=99... >=20 > 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. >=20 > 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=E2=80=99m familiar with the kernel development = philosophy (I used to be a contributor in a previous life). I=E2=80=99m 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=E2=80=99re 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=E2=80=99s why I=E2=80=99m 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? Cheers, Thibaut=