From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0856421F40B; Sun, 14 Jun 2015 12:32:07 -0700 (PDT) Received: by wifx6 with SMTP id x6so58293113wif.0; Sun, 14 Jun 2015 12:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XInR4srfW90fFC2SKvK/Bwj//qW8sUzSG/XV+RwlAYA=; b=mdaJeI2j2fO5vHIl3/E0ivIkkjC6/vSrsH84p6x+7TBYr7OyIlrgpLIRYQ6sz3hTE9 7w+UamGR+4NdFgBQpnGHcbZ7IiOHy3z3kXRgIXxKAPu7Duv2GO9KkHuq7S/xVM2MGrB8 YziJfd4qB4ZtV70KjOtj6RCMEGhf3fP1ApTtiEj/uVRzhfQ3lw4cSp/qFLQYp29Xf5oP ef4H2ZSmo8eMiAj97VwwbhhnO1I1mCq5z37NleemMWI5P0HxVLyDdkPpgzTe9J3Pa/2f o4L2ZJDfIuAs55PHcoO1E6U+UgX2z6KPXZwypjPTU4zP2TTKSuXHM/NVxBFnYqqct/o1 h5MQ== X-Received: by 10.180.11.239 with SMTP id t15mr6414548wib.63.1434310325530; Sun, 14 Jun 2015 12:32:05 -0700 (PDT) Received: from volcano.localdomain (host-89-243-97-115.as13285.net. [89.243.97.115]) by mx.google.com with ESMTPSA id v3sm12544432wix.8.2015.06.14.12.32.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 12:32:04 -0700 (PDT) Message-ID: <557DD6B3.2050401@gmail.com> Date: Sun, 14 Jun 2015 20:32:03 +0100 From: Alan Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Cake] openwrt build available with latest cake and fq_pie X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 19:32:36 -0000 On 14/06/15 17:09, Dave Taht wrote: > On Sun, Jun 14, 2015 at 8:53 AM, Alan Jenkins > wrote: >> On 13/06/2015, Dave Taht wrote: >>> Hopefully, by creating a "tc-adv" package (now in ceropackages) we are >>> nearly at the last step for being able to do builds out of the main >>> openwrt tree. I am puzzled as to how to correctly override the default >>> "tc" package, but at least this built and worked for me the first >>> time. >>> >>> so you can kill any local mods to the iproute2 package in your own >>> openwrt builds, and merely add tc-adv to your own build instead, and >>> build kmod-sched-fq_pie and kmod-sched-cake, and walla! >>> >>> assuming this is now correct, the next step would be to push tc-adv >>> into some mainline openwrt repo (routing?) and get it and the kmod-* >>> stuff built regularly out of their build system. (and then! yea! try >>> some faster boxes like the linksys ac1900 and see what new breaks!) >>> >>> Anyway, my barely tested latest build (cake works, at least) is at here: >>> >>> http://snapon.lab.bufferbloat.net/~cero3/lupin/ar71xx/ >>> >>> This also includes the latest cake, although I disagree with jonathon >>> about the count/2 mod, might as well test. >> New build still works for my link :). (15/1M dsl in the UK). >> >> If I want to test cake continuously, I'll need to fix sqm-scripts to >> pass the cake ATM options. I switched back to fq_codel for now (that >> worked as well). > Patches gladly accepted (tc-adv now does parse the new keywords I > think) Yes to both. I'd already tested "cake atm" + "stab overhead". This time I was dropping "stab" and using "cake atm overhead 44", which tc accepted... Sigh, I forgot the main reason I watched for a second build. To be sure of "cake overhead" I really need to retest closer to the link speed. I have a specific method for it. The test is whether it matches "tc stab overhead" in allowing higher rates/lower latency on RRUL. As RRUL saturates the uplink, you have to account for high ATM overhead on the TCP ACK packets there. And the bandwidth consumed by ACKs (and their overhead) is significant on the uplink because of the asymmetric link rate. My pleasure at understanding this is mitigated by how long it took for the light to dawn :). > , and we really, really, really do need to confirm that the atm > code works in every circumstance. I'm still with you :), I'll have another go in a few days. I've got some pretty monitoring (smokeping) now, for if I get cake running permanently. It doesn't seem particularly sensitive to this stuff[1] but it should show any massive screwup in the rate-limiter :). Alan [1] it seems my link is already relatively good & my usage is relatively undemanding.