From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7BD8521F206 for ; Thu, 19 Dec 2013 03:32:16 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C96D9211E7; Thu, 19 Dec 2013 06:32:12 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 19 Dec 2013 06:32:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=ECzbzB3IK4LU+9DShQHUg75LITM=; b=QpEfbU4RSO/5sM+VQBUC4rasG/wP VAr9S2LOKplnZIM3lmQYK1LTWac5/MplNwEt1ZyqNQZrXboY8FMtzn+8Q03Ys14R 1jORmdFNLRYISoWMWdrNM2ZWZxhpkwMVlopMlQkRC4shWse/4GM1V7rNFEYVp1Ab RzUIYx6AK5h0/P0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ECzbzB3IK4LU+9DShQHUg7 5LITM=; b=lo1arluNwa+U+Pjo6Iv7zCPsjLopcjYiOzciOvO8b2IWv3Wq0KEVQi 1PBsH5Im/U9Tqy9IFntpb0d4UdFxHz5LgEu4LmPXrvIhxLPcOegCLtzreZr+I6o1 ip8z0BdfV0/KweBuFxeX56V1ZjN96xyXUR5d0/VfzjwPISg5fFMlc= X-Sasl-enc: dwq9o0f8nkdW4dyB2RDem0C/8lGRGlr/dCk1Eo7+gUF6 1387452732 Received: from [172.30.42.8] (unknown [2.99.240.111]) by mail.messagingengine.com (Postfix) with ESMTPA id 38677C00E83; Thu, 19 Dec 2013 06:32:12 -0500 (EST) Message-ID: <52B2D93B.6050501@imap.cc> Date: Thu, 19 Dec 2013 11:32:11 +0000 From: Fred Stratton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sebastian Moeller , cerowrt-devel@lists.bufferbloat.net References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> <0E267F91-3CC8-48F4-92C0-AD8BACA98FCC@gmail.com> <1FA2FD44-D715-4B50-BB5A-BAF61070970B@gmx.de> <31B5B61B-4E58-4C5E-8F33-710CCE0918F4@gmail.com> <52B2D917.6080006@imap.cc> In-Reply-To: <52B2D917.6080006@imap.cc> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released 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: Thu, 19 Dec 2013 11:32:16 -0000 On 19/12/13 11:31, Fred Stratton wrote: > 3 comments. > > Presumably you want these changes for some future use of the interface > by a wider audience, rather than current users of ceroWRT. > > There is an requirement for this less sophisticated user to turn AQM > on for ADSL. There are far more ADSL users than those who use fibre or > cable. In the UK, offered a choice, about only 25 per cent of ADSL > users migrate to fibre. The figure for cable is 10 per cent. This is > in a fairly open market with competition. > > I would argue that the default should be 'on'. > > You state the choice in the interface pull down should be 'ethernet or > 'atm'. Currently it is 'ethernet' or 'adsl', which semantically makes > more sense, even though it uses a mystic, undocumented tc-stab option, > namely 'adsl'. > > The 'adsl' option appears to work, which is why I advocate it. > > Finally, the fourth of these 3 comments... > > OpenWRT developers are working on the TP-LINK TD-W8970, a gateway > device containing a Lantiq SoC. The device is cheaper in Europe than > the US for a change. > > Lantiq apparently have open-sourced their code, and the device will be > able to connect to the internet via ADSL2 or VDSL2, extending its > capabilities. > > Your interface will need to be modified again for a gateway device, > rather than a router. > > > On 19/12/13 10:49, Sebastian Moeller wrote: >> Hi Rich, >> >> >> On Dec 19, 2013, at 05:12 , Rich Brown wrote: >> >>> Hi Sebastian, >>> >>>>> Perhaps we could extend the Interface configuration page to add a >>>>> “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. >>>>> Default would be off, but when customers go to the GE00 interface >>>>> to enter their PPPoE/PPPoATM/ISP credentials, they’d see this >>>>> additional checkbox. Checking it would feed that info to the AQM >>>>> tab. (And perhaps there could be a link there either to the AQM >>>>> tab, or to the wiki for more information.) >>>> I am happy to include a link to a wiki, but I guess we first >>>> need a wiki page :) >>> Is this a challenge? Well, I accept! :-) >>> >>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 >>> is a draft. I recycled the images from a previous message and wrote >>> the least amount that I could that is likely to be true. >> This is great, thanks a lot. I have made a few changes to the GUI >> yesterday, which hopefully improve the usability, so if the new GUI >> passes muster with the cerowrt crowd, the screenshots will need to >> change as you note on top. >> >>> Please send me comments (or edit the page directly, if you have >>> permissions.) >> I do not have edit permissions, so I just comments here. >> >> Basic settings: >> Why 85% as starting point? And can we give instructions how to >> measure "degradation in performance", so that non-technical users >> have a chance to actually optimize their own system? >> >> Queueing Discipline: >> Maybe we can add a link to the mail list page >> (https://lists.bufferbloat.net/listinfo/cerowrt-devel)? >> Also can we note that it is recommended to turn ECN off for the >> egress, as we handle packets before the bottleneck and dropping >> packets actually allows us to send other more urgent packets , while >> on ingress it is recommended to turn ECN on, as the packets have >> cleared the bottleneck already, and hence dropping has no bandwidth >> advantage anymore. Both dropping and ECN should have the same effect >> on TCP adaptation to the path capacity. >> >> Link Layer Adaptation: >> I think the first question is: Do I have an ATM carrier between >> your modem and your ISP's DSLAM? This typically is true for all ADSL >> variants. >> The second question is: Do I have overhead on the link outside of >> Ethernet framing? This typically is true for users of PPPoE and >> PPPoATM and even Bridging I think. >> >> If the answer to any of these questions is yes, one needs to >> activate the link layer adaptations. >> In case of pure overhead select ethernet, in case of ADSL select >> ATM. >> Fill in the per packet overhead in byte (see: >> http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, >> http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ >> and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is >> zero and no ATM carrier is used, then select "none" for link layer >> adaptation. (I changed this page, so the tc_stab htb_private >> selection is under advanced options, and there is a selection of >> "none", "ethernet", and "none" in the first drop down box, "none" >> disables the link layer adaptation. Also the drop down box contains >> some information which selection is relevant for which cases). >> >> What’s going on here? Why do I need this?: >> I think we should mention that only with the proper link layer >> selected and the overhead specified cerowrt is able to assess how >> large each packet is on the link to the ISP, and only then the >> shaping is deterministic. (For ATM users without the adaptations the >> shaper is stochastically too optimistic about the link capacity >> (which is too say the shaper is too optimistic about the effective >> packet sizes)). >> >> Best Regards >> Sebastian >> >> >> >>> Thanks. >>> >>> Rich >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >