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 45D2E3CBE5 for ; Fri, 8 Apr 2016 15:20:36 -0400 (EDT) Received: from [172.17.3.193] ([134.2.189.253]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MXIov-1bKtuI20If-00WIro; Fri, 08 Apr 2016 21:20:27 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <57066793.5050608@gmail.com> <056D9AAF-85E2-4849-A3EC-4CE77276DF24@gmx.de> <57079B2F.8070607@gmail.com> <66A42333-0801-45AF-B67E-B7CFAF22FE43@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Fri, 08 Apr 2016 21:20:24 +0200 To: John Yates ,John Yates CC: Richard Smith , "cerowrt-devel@lists.bufferbloat.net" , Richard Smith , "cerowrt-devel@lists.bufferbloat.net" Message-ID: <57757B26-F98C-45D3-B410-9A18A0054EB3@gmx.de> X-Provags-ID: V03:K0:QCdQ5Gov1aWHzjFrKFB772H8ZDyARqQ/bkf2CwKnUxdYy2A8khD OQo3XE8nNx+b8ZfbKdcA8uGRbu00ns8ksAuAMAQijZZ2JbedEq5U04bRzU4bYpzdyJ+yiZG mZft0VNJ6KwUmhviUULCyABFY2popgx1RvUMBMWAoUrZcWU8VN43BNdRoxOZibtXC7gW92U L/LfkgVBhxGEK5UOYp8Xg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/3rTzqIVtdw=:VAht8SgpxR7H4gtcYnLFdx 1vz7OgEo93F9iJfgWs1DTHmcdqnLgcQ0YSa0m0znD9YY1MOjAK29RhDdjI+0P4rRjH15U5hFB C8sMTkQQlsKhG1WEsdv4Y/jQmaNobhG3Cpsfe9CLwAURlQHgXX2CceEqOn6KrkIq5ARxlt/gm 2kxI/Y5Is+kSWjsZjcN1BZQgBJBeKHNQk1Ee724QLAxpuyqpU75raWHE0+zile3VMVJ4FDn6M b4+dPPoRBn/RGxoUSsJ182qH+6LX1gYs5CA8c+RDz47AyHka5sBYzELrKic7vmsewTAgre+xK SHWUBl88pPnoP6R3dO9DaEoA3F0HMcz/MVED3RY/yqLYvTBjIDTO+9GmAfkB6T5EQmNR2RbQ+ hfjNTa3Jhq/xj0zE7OGSD0qzZ/acqhyR7mcjkvmLZmG1z+zaAlTBUXueTjMF+9coqvOc0l3EW rXwHH9mIiBATJTeFmcxFXEMow4jQGecdurBGCT96PZuPKmTdqm26yLcylzl+e9JC6uK5BMQa/ hJrNRbXqv1cA4Ig/jVVTbHEkgr/eFWsEZU6VbQtxmzIw/GDOErJfzZBWd9v06dL9I1m965Mca 3bKQjLaEhXS6HdGeyIHn4BFibqWPCoTjIvmgrAUhq/wmrn7rzyUcdy88gFLzGPEP9TijbMz8L 4kR7/dSEGfED1GW85ZhBJTUvI0JZTsIYeNobC8uEcksDOZWPmnZta+A4wNv5LqbiNme8DLhTu J6OUEQ0MLXDZ0gX2zelYHKX9faDvfPpnIOAENx8LoE/SGh8KMwMkBhhuKxFd94P+BTosG21eL F48WsNF Subject: Re: [Cerowrt-devel] Linksys wrt1900acs rrul traces ko X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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: Fri, 08 Apr 2016 19:20:36 -0000 Hi John, On April 8, 2016 3:55:21 PM GMT+02:00, John Yates wrote: >Sebastian, > >Recently you wrote: > >In your case select Ethernet with overhead, and manually put 24 into >these >> packet overhead field, as the kernel already accounted for 14 of the >total >> of 38=2E >> > >and further down: mi > > >> I assume in your case this will not change your results a lot, as you >most >> likely used full MTU packets in the test flows, I believe your low >latency >> under load increases show that you have not much buffer bloat left=2E= =2E=2E >I >> would still recommend to use the correct per packet overhead to be on >the >> right side=2E=2E=2E >> > >As a layman hoping to use some of this great technology on my forth >coming >Omni Turris boxes how am I supposed to derive these num Mkbers? Is there >a >simple series of questions and answers that could figure them out?=20 Well, yes and no=2E Yes there is an underlaying implicit decision = tree that could be turned into a series of questions that allow to deduce t= he required per packet overhead=2E And no as far as I know there is no expl= icit version of this=2E In the end it really is not as complicated as it may seem: 0) decide whether you really need an explicit traffic shaper at all=2E If no you are done, else 1) research what kind of link you want to shape for, as different link tec= hnologies have different overheads=2E=20 So typically you should ask yourself what or where the usual bottleneck li= nk in your internet connection is located, shaping works best for links tha= t are have fixed parameters=2E Good examples of technologies and links to s= hape for are e=2Eg=2E ethernet for an active fiber link (FTTH) or ATM for o= ld ADSL links, or PTM for vdsl2 ( FTTC): A) Ethernet=2E This is the signed easiest, just figure out what is used on= the wire=2E Typically that contains the the overhead described in my mail = to Richard with the potential addition of up to two VLAN tags (4bytes each)= =2E B) almost ethernet=2E Some technologies carry Ethernet frames so are simil= ar to ethernet but don't deal in all components of Ethernet, e=2Eg=2E vdsl2= 's PTM usesmuch of an Ethernet header but uses no preamble or ifg, but adds= a few specific options=2E C) ATM=2E This is both complicated and 'solved' at the same time, see http= s://github=2Ecom/moeller0/ATM_overhead_detector for references=2E Note this= not only affects the per packet overhead but also the link rate to payload= rate calculations due to quantized 48/53 encoding=2E D) PTM=2E Similar to ethernet except it introduces a few potential overhea= d items that are not shared with Ethernet and it also affects payload rate = calculations due to 64/65encoding=2E So ideally at this point you know what true rate your bottleneck link allo= ws and what overhead is added to each packet=2E Now the only step left is t= o figure out how much overhead the kernel already added to each packet's wi= re-size and reduce the configured per packet overhead by that amount=2E The devil, as so often is in the details ;) ' >Could >those be turned into some kind of "wizard"? =20 I am pretty sure this could be turned into a series of question's = or rather a sequential recipe but it will stay laymen unfriendly (with the = potential exception of ATM) as it requires intermediate type technical know= ledge about behaviour or links outside the user's direct control=2E Typical= ly your ISP would know all this, but there does not seem to be a universal = way to query an ISP to get the required information=2E Otherwise how do you >expect >large numbers of users to get their systems properly configured?=20 Honestly, I believe the only real hope for the masses would be a u= niversal adoptation of BQL (byte queue limit) in all CPE and CMTs/DSLAMs=2E= =2E=2E That or doing a bit of research them selves=2E >Surely >you do not want to engage in an email thread with each user who even >attempts such configuration :-) I agree, I believe the gist of a few of such discussions should be= turned into an FAQ=2E=2E=2E Best Regards Sebastian > >/john --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E