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 16AD121F420; Sun, 14 Jun 2015 13:43:55 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so7890916wic.1; Sun, 14 Jun 2015 13:43:54 -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=zSLSxHe1ib6i1JTyLrd6zTCnZQQtvmkxo3Abj7a6d4Q=; b=Q1PV8cRzUeI/4PTjpDy8DMeL9cBxzq35Bp1c8WoWpg35EG4SP8x2HlZTVKOtfyGBLv gbqQDnrpoICHU0DYXaG+iyNoSSuU30hK5BrXLCtSXP9VUhNL+o1iiMlyxQwMguSb3IGM iqZNiiK0L4qiKd1+cUsnDhcDeUESkzpafi0us6PbDhUX0NfXrq/9667gzAdFYEc+aKjE qp7WD460e8be0fDeg95rrVvoW9GtsdQsDTfdlcEeVdAiLR46ok8gm56ERncZxsDae91l /uxKCJ4w095tjQDYh/7FR+mf2MhjN1ABhEHiM9JDa6DZLr3IQFVoOfOUIUqkICPqvMJR iwSA== X-Received: by 10.181.11.229 with SMTP id el5mr25889718wid.40.1434314633977; Sun, 14 Jun 2015 13:43:53 -0700 (PDT) Received: from volcano.localdomain (host-89-243-97-115.as13285.net. [89.243.97.115]) by mx.google.com with ESMTPSA id hn7sm15845258wjc.16.2015.06.14.13.43.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 13:43:53 -0700 (PDT) Message-ID: <557DE787.6080900@gmail.com> Date: Sun, 14 Jun 2015 21:43:51 +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: Sebastian Moeller References: <557DD6B3.2050401@gmail.com> <972CD700-1945-4ADF-A559-55B166FC2543@gmx.de> In-Reply-To: <972CD700-1945-4ADF-A559-55B166FC2543@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 20:44:24 -0000 On 14/06/15 20:47, Sebastian Moeller wrote: > On Jun 14, 2015, at 21:32 , Alan Jenkins wrote: > >> On 14/06/15 17:09, Dave Taht wrote: >>>> [...] >>> 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… > Just to be explicit: this combination worked correctly? Yes. I found "cake atm" + "stab overhead" worked fine (and reported it on the cake list). > If so, changing sqm-scripts to allow the cake way of specifying overheads gets less urgent… If I'm reading the code correctly, sqm-scripts doesn't use _any_ way of setting overhead when qdisc is set to cake. Maybe I got it wrong though. (other todo would be to add cake to luci-app-sqm, doesn't bother me either way though) > Did you by any chance also try to use tic’s stab method to specify overhead and link layer ATM? If that does not work sqm-scripts need a fix quickly anyways (otherwise people will get tangled in our crafty net…) Hmm, looks like I didn't record that. I thought it works but I'm not sure now. > I am currently mulling over how to include cake’s more user-friendly way to specify overheads into sqm-scripts, and have no good solution yet. One hack I would like to propose is to attach the “Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully.” to the cake invocation to allow early adopters to pass arbitrary strings to cake, so they can keep the guy. The main issue is that this comes with no safety checks at all, and I have no idea how cake deals with wrong inputs (as I have not been able to build it under opens use 13.2 yet). > >> 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. > So for me the following worked well enough: set the shaper to the exact uplink sync rate as specified in the modem, run RRUL against the nearest server for 300 seconds or so, with the correct overhead and link layer options. On my link latency under load started to increase sharply once the overhead was reduced by a single byte. > This sensitivity actually allowed me to catch an episode when my ISP had increased the overhead by 4 bytes temporarily (after the RRUL results I re-ran my arm-overhead detector which confirmed the increase by 4 bytes). Pretty sure I have to set the rate lower :(. Maybe an ISP shaper or policer like you mentioned noticing. > >> 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. > Back of envelop calculation gives an estimate of 2% of downlink-bandwidth as reverse traffic as ACK (before ATM does its dirty work and quantisation). It's getting late now :). But my theoretical calculation was much higher, and it matched the gap in measured bandwidth (tcp goodput) between a 1-way and 2-way test (rrul). 740 and 390 K respectively. http://www.dslreports.com/forum/r30046195-FYI-for-general-feedback-on-the-new-speedtest that said my calculation assumed 1 ack for each tcp segment (packet). Apparently 1 ack per 2 segments is also common ("delayed ack") and I didn't look at whether that happened in my test. >> My pleasure at understanding this is mitigated by how long it took for the light to dawn :). > Yeah, I guess you will not shed a tear once ATM goes the way of the dodo? I like your jokes. Don't you know, old technology never dies :-D > Best Regards > Sebastian > >>> , 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. >>