From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 05C1E21F36B; Sun, 14 Jun 2015 12:47:55 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqzIJ-1ZZ8n523lr-00edru; Sun, 14 Jun 2015 21:47:52 +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: <557DD6B3.2050401@gmail.com> Date: Sun, 14 Jun 2015 21:47:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <972CD700-1945-4ADF-A559-55B166FC2543@gmx.de> References: <557DD6B3.2050401@gmail.com> To: Alan Jenkins X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:YOkgoavQKvDGzzAkEDaFV9fFfMJ17hSsdqhmaEoL387rQcFqm3o HXfzHVNyKmEU/MXsLEStvZoXPv6FBJa411TRrWclvsa1FUvYoEzs/x6uQSeyXxHV9WZ/s9D Bu/yP7ax0T5IreoKna16PbrnUmRNzV7pZuYMRhoCsDvAEa6dhJ/T2a8f+s2jxL0hxqg0skL B7EJnIIv+1VEsptaFHYxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1HtKWu5j20o=:EQsuGnUzFc7SnyvbBO97M/ 6mK1tF9Nbf8dbVHf9EjFyhU5lOvJnRPCrmOPgJ2W2y5MouMqiIcf9BU2F1ohVEzIdx/u+Fg8u ORLAnolTU5nMJZRY1zWV48vZU7UWJ2Pn20HrX8V7/UPoFVyeP9ry7qh7wkgbrWnXZbLYLA1RC jyX1ee2nzT23YrcMSv+/wflOnVScQmiHPoOMM/v5KYwP/WsN4kib6RI4zPPLJIBq4ImMQC2N0 qIIhIOMAu8nqrtKHz+DX+brvqbbGGUDvUVaDUS0claGCSwea/6Hc50R5vAFw/JJOhfbYtS0qA BWvYgykBpiK+MqHu4fDzDXIGvNCyTFz97Hm51bMz5LAmN/E8+NuBsb618cjV87Cc50nKTB48k U35cX77peb3CxDqm9TKIdXwKm6uQ5ZVZGOfpPwzc4K7QXOVQEJKQSZm/WrL49CdvEuQbr1uh5 4X+qHpkCguK84Sa4RUAlO/yaXj/n3LXjp6w/2r1+PDDA9LelJ62r8hULr5V4QOQb0TFjxA9MZ EIQJgzmxJ+U3ChVryO6YMf73UCF2Mo4YLQBdIbTiLEZ7QYPMyBnmk/Mz8lsnBzAmf17uXDa2h uUAJ7gEEotg1PE21Wh3TuzLRR2t69sRnk99Rp2M82ZzxWHb/YPuH7XlQaOq1Ag43pZFBewM7L hGA9X+UWQu+H2ZmB+GhSUpFNzOndHrbBNZYIHdQqvCFx+CZ3pPjRL/+7369Z+l1XJVWo= 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:48:24 -0000 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) >=20 > 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? If so, = changing sqm-scripts to allow the cake way of specifying overheads gets = less urgent=85 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) 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.=20 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 > 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. =20 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). > 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? Best Regards Sebastian >=20 >> , and we really, really, really do need to confirm that the atm >> code works in every circumstance. >=20 > 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. > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel