From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DEC883B2A4 for ; Sat, 14 Dec 2019 16:35:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576359317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zclUt0k4jY3UC0Z3vrI0Yg1kUgMCXiMCmXq2exoD4mo=; b=MJWHb8hsqLP/4SSvZKGg/bHLYYYI6oUFJzWnEWP9+XbUYhwR6pRPwzuvme7Nz13ejavrae Yg7Gzi6Bscz6+ag2JpxqexGd424iy1QX9XlqUQqR/znDBnQC1ELO1kqzmWbnuJFovrRj/0 x5Yk2f3w9Sa/mx0hwynGm5e5yavkkUI= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-25-gSXlSNC3Pcu0R0HlqMzK3g-1; Sat, 14 Dec 2019 16:35:15 -0500 Received: by mail-lj1-f199.google.com with SMTP id b12so808957ljo.11 for ; Sat, 14 Dec 2019 13:35:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=zclUt0k4jY3UC0Z3vrI0Yg1kUgMCXiMCmXq2exoD4mo=; b=GDfBZuZvvDKzodDGbOhNeQ0MW+QE+W9MPhk/L2mYh+iQMJKI0gC8Li1WQTXGxoCxDq 2lhY8xf8DTHLTYPQ5A+KGK8/alxpyd+v0UnpFE185GfM6xi+UJkU1F1s49FMnJbod/XR pqUf+lXHVvUi5/S4Y0myPy328p0P143cohh9bgMrjtnaricAkMeNlYtYf7EkpA+LPCQy lRg/NdQqGLgOssLS+vg5f5khCz06Z7l7ZJQJNwGz8LwyO2QfzzhS36Tft0R+6PKc/W/r 18XM6VNmabkc0eJW5GDH4O71eIkU+RbiPJzEvgtiayGW+UAZA8k0ReFP6Z3L0AF2mf4X 5H5A== X-Gm-Message-State: APjAAAUZ7kPx9LdzjnEOfWLPVbeCXuKUcFRFmQjmDWHZz45hRNE3X9Lb 1Lhh5cXiTbmmAbHRhRGhk8yDPLKmyUvgXqePgumo+A795R26Lidh4OAdHi0T1p7EIfnJaufXLDf CcT2UqUKtXcPSjduJmaI6gw== X-Received: by 2002:a2e:80cc:: with SMTP id r12mr14061205ljg.154.1576359314531; Sat, 14 Dec 2019 13:35:14 -0800 (PST) X-Google-Smtp-Source: APXvYqyTzbtF70wzJfbMJ8v9lorY/rfzWPklYkSv0Flb952tY0J4G0XwRN6gD4Cs+v71I4f2rfYqHQ== X-Received: by 2002:a2e:80cc:: with SMTP id r12mr14061193ljg.154.1576359314344; Sat, 14 Dec 2019 13:35:14 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id k25sm7228760lji.42.2019.12.14.13.35.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Dec 2019 13:35:13 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id CE03D181A44; Sat, 14 Dec 2019 22:35:12 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Thibaut Cc: Jonathan Morton , Erik Taraldsen via Cake , Kevin 'ldir' Darbyshire-Bryant In-Reply-To: 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 14 Dec 2019 22:35:12 +0100 Message-ID: <871rt6d20f.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: gSXlSNC3Pcu0R0HlqMzK3g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 21:35:17 -0000 Thibaut writes: > 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 wrot= e: >>>>=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 uninitializ= ed data=E2=80=9D type of bug. >>>>=20 >>>> This is why I wouldn't keep working on an old kernel that's full of ve= ndor 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 philo= sophy > (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 pro= vide > 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 pos= sibly 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