From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E2C3521F420; Sun, 14 Jun 2015 13:54:52 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlV4F-1ZcTkc2AtT-00bGAx; Sun, 14 Jun 2015 22:54:49 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <557DE787.6080900@gmail.com> Date: Sun, 14 Jun 2015 22:54:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <739CDC7A-CD5E-48FF-81FF-8E13C1086523@gmx.de> References: <557DD6B3.2050401@gmail.com> <972CD700-1945-4ADF-A559-55B166FC2543@gmx.de> <557DE787.6080900@gmail.com> To: Alan Jenkins X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:1w+EhZClSp74hqQ8u0yjiGt5+1HwySP6o0erjw9P6sBGEJxS8rd SyJzYmcQdUeJ2pjciR+rUEueCooshPPWn9oEtZGjhwKWzyV5Y/Zfb98bkmhNkm6KuW59lQ7 vNtS2Ac+7x1yJjosSrnmYi2/nvE1aw8qPINFamjg/UAo2Jmef8GBqF9owbsmorzeNxJD1vu Cd+4+2S0Du+9G34fy9zKw== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cake] [Cerowrt-devel] openwrt build available with latest cake and fq_pie X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 20:55:21 -0000 Hi Alan, On Jun 14, 2015, at 22:43 , Alan Jenkins = wrote: > On 14/06/15 20:47, Sebastian Moeller wrote: >> On Jun 14, 2015, at 21:32 , Alan Jenkins = wrote: >>=20 >>> 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=85 >> Just to be explicit: this combination worked correctly? >=20 > Yes. I found "cake atm" + "stab overhead" worked fine (and reported = it on the cake list). >=20 >> If so, changing sqm-scripts to allow the cake way of specifying = overheads gets less urgent=85 >=20 > 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. No, you are right, it is not hooked up at all, my bad. Since I = still fail t building cake I can not test it, and my track record is bad = enough with changes I could have tested, that I want to avoid checking = stuff that should work in theory, without any testing ;) > (other todo would be to add cake to luci-app-sqm, doesn't bother me = either way though) >=20 >> Did you by any chance also try to use tic=92s 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=85) >=20 > Hmm, looks like I didn't record that. I thought it works but I'm not = sure now. If you could retest that some of these days I would be = delighted, but then cake=92s and ht.=92s ways of dealing with ATM are = more generic than tc stab=92s so maybe I can not avoid doing the cake = changes anyway... >=20 >> I am currently mulling over how to include cake=92s 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 = =93Advanced option string to pass to the ingress queueing disciplines; = no error checking, use very carefully.=94 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). >>=20 >>> 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). >=20 > Pretty sure I have to set the rate lower :(. Maybe an ISP shaper or = policer like you mentioned noticing. Isn=92t it great, every ISP a snow flake ;) >=20 >>=20 >>> 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). >=20 > 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. >=20 > = http://www.dslreports.com/forum/r30046195-FYI-for-general-feedback-on-the-= new-speedtest >=20 > 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. I believe the RFC=92s state at least one ACK every two MSSs, and = if I look at iftop while running rrul tests (under macosx 10.9.5) i get = something close to 2%, but I tried to hedge with the =93back of envelop=94= ;) >=20 >>> 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? >=20 > I like your jokes. Don't you know, old technology never dies :-D Right you are, this is partly th reason why I think that cake = should be able to solve this for unsuspecting users that might be = trapped on planet ATM for years to come. (I always wonder whether ATM = gear really is nearing EOL or whether it will get a second wind in a = less developed market; I certainly hope that it truly dies one of the = days, like vampires ATM has its charms and yet the world would be a = better place without ;) ) Best Regards Sebastian >=20 >> Best Regards >> Sebastian >>=20 >>>> , 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 :). >>>=20 >>> Alan >>>=20 >>> [1] it seems my link is already relatively good & my usage is = relatively undemanding. >>>=20 >=20