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.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C35273B2A0 for ; Thu, 2 Jun 2016 14:53:07 -0400 (EDT) Received: from [10.136.220.202] ([95.91.196.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MUpFU-1aymGJ2QH6-00Y6zS; Thu, 02 Jun 2016 20:53:03 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Thu, 2 Jun 2016 20:53:00 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <0EDA2CBF-E6FF-449F-ACDF-909526CEE140@gmx.de> References: <574FFE52.1040501@darbyshire-bryant.me.uk> <2A84540D-AA30-4BD0-AF9A-5510EA00B7E8@gmail.com> <87a8j3fyxc.fsf@toke.dk> <6F215C7B-D4B2-484B-B728-61E0B83FF30E@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:p3xKPN/VT9a9HW99SgTBHQuaTC098k4oX80r9ZFWOmmA4kAKfxH dfvoIqlDIK6zXVX4dJx83cu0c3nu1JAUcqeLGhUOeJEFiIYMCyRL+rnRN7xKvcmq4fndwAQ 2d1T2nvWR0VQO2RzZofA+iJtXFvqf28FQnq3Zk08LxVXjhecvViktjWpgoe/uYPB5oH/pKZ 58Cgw1Mk95yEMqF9+xurg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3qbN458rmhw=:aExGxFsdePtGtrJn2aAcbZ LdfJObYGgveb640nRfdLD/kS3Esz6YigMDbp6WOypCu94LhbxHWuuAsA/BE0D9eUJJJ1hkWfp meBHWfmjXrJ0tkeyNJIVsV0tvC6W4bt2gTVGS4vlmHeNa5qi30k8eix/GTsaSTXQ5XkWn1OkW loQGOl76CovZwWZMiMnLroua0fMqomIoG4YPytvDXmSBE7CJYYbPW4q62uDoMQXA+kIV0KyDZ Lt7xETMthGy5GSsAN4OZ3PaOGLj9K1T79nK1jiwkvmQY2ZpXr4xODqJ3CkMuHuO7j6n42hM9p pz+nNuCtrA18t7eyysx2BI1eZ5pxlukYC70UTqn49O/61/aWRbRdtqUDuXHlt+sArg6cl3XYd pUbufWWtu7lk1b16A54zYINzqUyV4ctSW3wsDeWBgGnmyTZvXL9mEF/6EbJ2sLeDa1BB5/x/j maS/Y97WnupD1yKzsy+fDZ4gCAoLx7A/+a2rgS1QkuMM3g+gAvv0RiUhqjM/6+UA0ohYoSDTy VGnrpdqW5FvqtXwO+yg0CtUjlw081Y9K8O9/c15KGFgjygpQM+IQPl/e9+dXIfEKEB2RUmVDF YtkGN9QesaO+VEgRuN7dNsFky313E41ezU50LCQzYSa2ntHtM0uvzWfyjtutLUOQkgPvJE0m8 oDyC1rTnnVebLMixatC1/JnSjTEK4kAhKfvPeQ19xID2O3k0bi9v4hRq168SuR2uQ4DXTHBxt dBtNPKz+IhfHMGyhy566/i7/MEkW36+/1RprDHgn4LEB9ZDeud8R//08FC2GRbGxc8Ejmu59W Z2kkZqG Subject: Re: [Cake] cake/tc - removal of atm/ptm/ethernet specific overhead keywords 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: Thu, 02 Jun 2016 18:53:08 -0000 Dear Jonathan, > On Jun 2, 2016, at 19:40 , Jonathan Morton = wrote: >=20 >=20 >> On 2 Jun, 2016, at 18:42, moeller0 wrote: >>=20 >> I stopped believing this is =E2=80=9Csimple=E2=80=9D a long time ago; = I also failed to come up with a method to measure the actual overhead on = VDSL links=E2=80=A6 >=20 > If it=E2=80=99s impossible to measure, then by definition it doesn=E2=80= =99t have a significant performance impact, That is unfortunately not really true=E2=80=A6 it really is just = that, hard to measure. And that might be more a statement about my = methodological/creative gaps than anything else. > and thus it doesn=E2=80=99t matter if it is sloppily estimated. In = that context an overestimate of overhead is safe. Safe, only if over-estimated; I would prefer if the user would = specify the bandwidth =E2=80=9Csacrifice=E2=80=9D once when he sets the = shapers brutto rate ;) >=20 > This is really a user-interface problem. I think it would be very = helpful for LuCI to get a basic, easy =E2=80=9Cconservative overhead = compensation=E2=80=9D button that simply turns on the =E2=80=9Cconservativ= e=E2=80=9D keyword for both ingress and egress. That=E2=80=99s the bare = minimum. That will, as currently implemented, drag in the ATM 48/53 cell = compensation for all users, eating roughly 9% bandwidth, not sure we = would do our users a favor with such a default policy.=20 >=20 > We can discuss details of improving granularity of that setting at = greater leisure, preferably in the context of a proper redesign of the = SQN configuration. >=20 > And let=E2=80=99s be absolutely clear: I will NOT drop the shortcut = keywords from tc. So far I have tried to raise a number of in-detail issues (in = other mails and postings) that seem to indicate that our assumptions = about per-packet-overheads are not as robust and complete as they should = be if we want to use them to justify changing the defaults. So, if you do not want to drop the keywords then please make = sure they are well-documented and consistent. Currently it is not = self-evident which numerical overhead corresponds to which keyword and = that mapping should be crystal clear. And I would like to add that = =E2=80=9Cconservative=E2=80=9D-keyword needs special care in = documentation as it is the only keyword that compounds = per-packet-overhead and specific framing (ATM in this case, we simply = ignore PTM=E2=80=99s 64/65 encoding (and rightly so)), this should be = obvious from the documentation (man page and the output of =E2=80=9Ctc = qdisc add cake help=E2=80=9D) and in my opinion the keyword itself. I = would propose as first half-measure =E2=80=9Cconservative_adsl=E2=80=9D = or =E2=80=9Cconservative_atm=E2=80=9D to signify the compound nature. =09 Best Regards Sebastian >=20 > - Jonathan Morton >=20