From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2E60721F151 for ; Sun, 29 Dec 2013 07:37:16 -0800 (PST) Received: from [192.168.2.43] ([79.202.32.60]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M8ehf-1VBoLb1BVj-00wCFS for ; Sun, 29 Dec 2013 16:37:12 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 29 Dec 2013 16:37:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70170FE8-40DA-4520-AD38-BBB957887CC3@gmx.de> References: To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:4l/nPWQBefuUZV7cKyCl/meG+YrgE96th0xuskufGP4mikLHQ6r 5c8wo/JGyDwENd2B5bEgUIYM/PQnL4DzTuqJ+X84l6iuteeuB072Ir0YtGuPSjOCQxcyH3i 7kQwaQTYGjcq3eAUSQEmM38AAcVov4YN/o4MLC0igENXAMEphN1HRZLmAOA58gQEvcS7Mzl 3Hl29mEtlitQREm3R5n9A== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] been writing all night 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, 29 Dec 2013 15:37:17 -0000 Hi Dave, On Dec 29, 2013, at 14:28 , Dave Taht wrote: > it is now 5:26 am. I have not had an all night writing or coding binge > since I quit smoking back in july. I bought a pack this afternoon. It > turns out that chain-smoking has benefits to my writing process... I > revised the aqm page >=20 > = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWr= t_310 Great, some comments on the link layer situation: > 3. Link Layer Adaptation >=20 > You must set the Link Layer Adaptation options correctly so that = CeroWrt can perform its best with VoIP, gaming, and other protocols that = rely on short packets. The general rule for selecting the Link Layer = Adaption is: >=20 > =95 If you use any kind of DSL/ADSL connection to the Internet = (that is, if you get your internet service through the telephone line), = you should choose the "ATM" item. This should read if you use any kind of ADSL line you should use = ATM, VDSL users should select ethernet (VDSL retained the ability to be = deployed over ATM, but to my knowledge it typically uses PTM, a much = saner transport layer for data) > Leave the Per-packet Overhead set to zero. For ATM, getting the overhead too small will on average create = one half ATM cell of padding per packet size that is not accounted for = by HTB, getting it to large will make HTB over judge the transmission = time on the wire, wasting a bit of bandwidths (again by half a cell per = packet size). Underestimating the overhead has a worse effect than over = judging it, so I vote for changing our default to an overhead of = 40bytes; with 44 being the absolute maximum and rare, and being 40 the = second largest and as far as I know the most likely with PPPoE, = LLC/SNAP, RFC2684 encapsulation. (Rant: =46rom a user perspective IP = over ATM would be the best, as it makes more of the payed-for link speed = useable for actual traffic). For non-ATM links, often telcos still use PPPoE (in Germany for = VDSL2, and even fiber GPON) so a small overhead of 8 bytes, I think = would be applicable. But given the typical fiber and VDSL2 link rates, = misjudging that will not have a really bad effect. (With ATM we have the = fact that the actual overhead is way larger and that it might drag in an = additional almost empty padded ATM cell.) Now, the recommendations in the wiki, should contain the = information, that with VDSL there is the slight chance of ATM = encapsulation and give a hint of how to diagnose that. > -- dtaht -- I am so unable to parse the huge email thread on the DSL = issue. >=20 > =95 If you use Ethernet, Cable modem, Fiber, or other kind of = connection to the Internet, you should choose =93none (default)=94, and = move on. Even though there might be a small overhead on all of those, I = think this is sound advise to keep things simple.=20 To complicate things further VDSL1 uses HDLC as link layer which = would be quite nasty to handle (HDLC wire size is not simply size = dependent as in ATM, no it is actually data dependent, with worst case = 2fold increase from data size to wire size, that would require to = actually search each data packet for occurrence of octets that will be = escaped on the wire) if VDSL1 had a significant deployment, that is... > =95 [What is the proper description here?] If you use PPPoE (but = not over ADSL/DSL link), Select ethernet and specify a proper overhead, I assume 8 bytes > PPPoATM, You are on ATM, hence enable ATM, 40 bytes overhead will waste = some bandwidth but retain latency. > or bridging that isn=92t Ethernet, I have to pass, no idea... > you should choose [what?] and set the Per-packet Overhead to [what?] > If you cannot tell what kind of link you have, first try the ATM = choice and run the Quick Test for Bufferbloat. If the results are good, = you=92re done. You can also try the other link layer adaptations to see = which performs better.=20 Mmmh, the ATM link layer adjustments will work on all = underlaying carriers, as it will effectively just estimate a wire = transmit time > ethernet transmit time. So on non-ATM that just results = in more bandwidth wasted, latency stays well. The proof is rather the = other way around only with link layer ATM, people on ATM link will be = able to set the shaped rates to around 90% at all. Unfortunately this = effect is most pronounced for small packet sizes and we have no easy way = for people to test the performance with small packets=85 (that said, = maybe reducing the MTU in the router might work, I need to test this...) >=20 > (which I'll rename and crosslink to a few other places) >=20 > and wrote >=20 > http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die Nice. >=20 > in addition to all the other emails that came out of me today. >=20 > I was unaware btw, that shaperprobe had found a home at mlabs. I've > been shipping shaperprobe in cerowrt since the bismark days, so > perhaps with an update to that and some code to detect sfq that I've > been winging about for ages, perhaps we can use that (and leverage > mlab's servers to boot)!! >=20 > Before I quit again I suppose I should take on a couple RFCs and the > other stuff in my writing backlog. :cough: :jack: :wheeze: >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel