From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 D5EFC21F19F for ; Wed, 18 Dec 2013 03:27:58 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9706120C12; Wed, 18 Dec 2013 06:27:57 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 18 Dec 2013 06:27:57 -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=CUxtXd4YoWQr1dYcBJWK2BWGz0I=; b=1j74IYS83nH2cxuV8Qj7P3kL8KF4 OdCWQPRKyt28Sjrtn6six/Y58z10M6Wjae2fI6e4GoWuEZCLFgOSHR901LCaBDCQ 8DayRIbbLmqgoxEvx7Di/WA3kD6vHzgBlzqiQNC4gb9/uRuWpCy5Cx63DUWzSpmn 3DmtlDUUvTmrizc= 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=CUxtXd4YoWQr1dYcBJWK2B WGz0I=; b=E2hJ8sl1YCj1vEohctUwqtLwDTOaAWXD834Ro8nrCx0cVZoPWNekPp fdFBxWiFgzZXtbrKXIKaStOfVIeMxwNlCbJoAHhwa+E5+ql3yqQ+BlMYu9UGDf65 5c8aIvo/FsUHhM2GJmqt6lt566HruzjuM9HNzhifpKJ8NPi/cvny8= X-Sasl-enc: +tDKL7BMotLwbIVWeTBVYgdirrTtf+z34rXFwdogMGHr 1387366077 Received: from [172.30.42.8] (unknown [78.145.35.142]) by mail.messagingengine.com (Postfix) with ESMTPA id C6882C00E80; Wed, 18 Dec 2013 06:27:56 -0500 (EST) Message-ID: <52B186BB.9010601@imap.cc> Date: Wed, 18 Dec 2013 11:27:55 +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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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: Wed, 18 Dec 2013 11:27:59 -0000 VDSL2 uses PTM. In the UK, the regulator has mandated that VDSL2 must be = run over fibre, normally to an MSAN within 200-300 metres of the user. So what is the fibre in your cable and fibre category? Is it FTTC/FTTH as I describe, or fibre using some other transmission=20 protocol? On 18/12/13 10:33, Sebastian Moeller wrote: > Hi David, > > On Dec 18, 2013, at 05:34 , David Lang wrote: > >> On Tue, 17 Dec 2013, Rich Brown wrote: >> >>> - From what you=92ve said, I don=92t have much hope for doing it auto= magically. But maybe we can provide clues to help the customer do to the = right thing. Perhaps the first dropdown could be =93Link Layer Adjustment= s (used on DSL or ATM)=94 with options for =93None/ADSL/SDSL/VDSL over PT= M/VDSL over ATM/PPPoATM=94 and maybe others. CeroWrt could automatically = set the proper link layer adaptations for each. We could also include a l= ink to the wiki for a flow chart for setting each of these cases, especia= lly the questions they should ask their ISP. >> Let's start with the first question, what is the difference between th= ese as far as what the config should be? > 1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): link = layer has to be set to ADSL > 2) PTM based carriers (VDSL2): link layer has to be set to ethernet > 3) cable, GPON (fiber): link layer has to be set to ethernet > > 1) and 2) typically have additional overhead to account for, 3) may or= may not > > Only 3) with no overhead is fine with no link layer adaptation mechani= sm. > >> forget the GUI or automated settings. If I am configuring a Cerowrt bo= x mmanually, what should I set differently for the different types of con= figs? > Current GUI settings (might change) > A) ATM based transports: > 1) Which link layer adaptation mechanism: tc_stab > 2) link layer: ADSL > 3) overhead: see http://ace-host.stuart.id.au/russell/files/tc/tc-atm/= (section: Overhead and MTU Calculations) > B) PTM based transports: > 1) Which link layer adaptation mechanism: tc_stab > 2) link layer: ethernet > 3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251= -Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based- > > C) cable, GPON (fiber): > 1) Which link layer adaptation mechanism: none, assuming no per packet= overhead > otherwise > 1) Which link layer adaptation mechanism: tc_stab > 2) link layer: ethernet > 3) overhead: unclear but see:http://www.dslreports.com/forum/r27565251= -Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based- > > There should be no need to fiddle with the advanced link layer options,= unless you link MTU is >> 1500. Note for link layer ethernet no size tab= le is constructed unless MPU > 0. > > >> What is the impact of getting it wrong? (if it's like VPN overhead whe= re setting the rate just slightly too high results is lots of wasted 'air= time' by setting it too low results is a amall amount of wasted 'airtime'= then a low enough value to be reasonalbe everywere is a good default) > User on an ATM based link without link layer adaptation: The shaper wi= ll underestimate the relevant wire seize of each packet and hence will no= t shape enough to avoid filling the potentially bloated buffers of the DS= L modem. This effect gets worse the more the packet length distribution i= s skewed towards small packet (the estimate can be off by around 50% wors= t case, so this is not good.) But note this basically is the "status quo"= for most users (as far as I know no router/modem sets these options corr= ectly, but I do not claim to know all such systems). ALSO this in theory = is testable, on such a system buffer bloat/latency increase should be mor= e severe if one tries to fill the nominal transmit rates with small than = with large packets. Misjudging the overhead either wastes bandwidth or al= so if too large or increases the likelihood to see buffer bloat by overes= timating the effective link capacity. > > Users on a PTM based link, when running with link layer ADSL, will wa= ste 10% of the bandwidth right there (for taking the 48 in 53 encapsulati= on into consideration). Plus they will overestimate the effective size of= small packets and will waste up to 50% of the remaining bandwidth there.= Overhead misjudging has the same effect as on ATM (except overheads on P= TM typically should be smaller I guess so this effect might not be too re= levant). > > To summarize, using the wrong link layer adaptation will hurt the user= , ATM users will suffer buffer bloat, but will use all available bandwidt= h (well more actually since that creates the bloat), PTM users will suffe= r severe packet-size-dependent bandwidth decreases. The "status quo" is m= ore or less fine for groups 2) and 3), not so good for 1). I think most p= eople in 1) caring enough reduced the shaped rates by a larger amount tha= n people in groups 2) and 3) and just accepted that depending on the pack= et size mix latencies got more variable. > > Getting it wrong is not advisable=85 Getting it right requires some no= n-obvious information from one's ISP. While VDSL will become more promine= nt in the future, ADSL variants will not disappear for a long time, as VD= SL only works (well) > on short loops, so people far away from the DSLAM will stay on ATM (or = one day a new ADSL might learn to use PTM, but I will not hold my breath)= > > Best Regards > Sebastian > >> David Lang_______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel