From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 84C5421F0FA for ; Mon, 6 Jan 2014 02:57:07 -0800 (PST) Received: from hms-beagle-3.home.lan ([217.254.130.56]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lrviw-1VGR9h0AiU-013iAA for ; Mon, 06 Jan 2014 11:56:59 +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: Mon, 6 Jan 2014 11:56:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A0169F3-2B57-4AFE-916E-66E32E782C50@gmx.de> References: <01558084-B7D8-448A-A4ED-CE36D18AAA97@gmail.com> <52C855B1.1040209@imap.cc> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:SJEc/wRPaeFLAsQ/qsBciJf9Hx6U9WRS0MzVm3NnleIaDxwrY2i 4xG8+gn8rjORr1E6JT6RH4f0HsbSA7KM8YQmMzH794Lvv7wevN/itY1yvTuZcXrIPOIHio6 X64h6D9glF66UUiYu98neZ4vCgM3IfvuAUtreSs81QjP5kJOCXFq/GQJeoZ3JsnyF03I0nf 8fJT1TUWwQOh6cY6RRJYA== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] SQM Question #5: Link Layer Adaptation Overheads 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: Mon, 06 Jan 2014 10:57:15 -0000 Hi Dave, hi List, On Jan 6, 2014, at 04:29 , Dave Taht wrote: > On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton = wrote: >> Link Names: >>=20 >> For consistency, if ADSL is used as a portmanteau term, them VDSL = should be >> used as the equivalent for VDSL and VDSL2. >>=20 >> CeroWRT has to decide whether it is an experimental build, or = something that >> will eventually be used in production, so these decisions can be made >> consistently. >=20 > Well, what I was aiming for was for us to get the sqm scripts and gui > up to where they were better than the standard openwrt qos scripts and > then push them up to openwrt to where they could be more widely > deployed. >=20 > Aside from being able to dynamically assign priorities in the gui, we > are there. Except that nfq_codel is currently getting better results > than fq_codel at low bandwidths, and I'm tempted to pour all of > simple.qos into C. Since you wore nfq_codel, what is the secret sauce here? >=20 > As for cero's future - certainly since all the snowden revelations > I've been going around saying that "friends don't let friends run > factory firmware". I would like a stable build of sqm and cerowrt to > emerge, and to then go off and work on improving wifi. Regrettably > what seems to be happening is more backwards than forwards on the > former, and ramping up on the ath9k and ath10k is taking more time > than I'd like, and it seems likely I'll be working on those primarily > on another platform and only eventually pushing the results out to > cero, mainline kernel >=20 > So it's still at the "keep plugging away" point for sqm, ipv6, cero in > general, with the stable release always just out of sight. >=20 > Tackling the ipv6 problem is next on my agenda on cero, and getting a > test suite going is next on my day job. Any further hints on the nature of your day job possible :)=20 >=20 >> I concur with your ADSL setup suggestion as default. I have been = running the >> Sebastian Moeller ping script overnight to calculate ADSL overhead = for the >> last several days. After several hours of curve fitting using Octave, = an >> overhead result is displayed. This novel approach works well. >=20 > It would be nice to get to where we could autoconfigure a router using > tools like these with no human intervention. This includes bandwidth > estimation. I fully agree that it would be nice. Also it ail e hard unless = we take control over the actual bottleneck link=85 With DSL connections, = the DSL modem knows a lot about the link properties, if the modem would = be onboard we could programmatically as about bandwidth and = encapsulation; for the more typical case with an independent modem or = even modem router we have no clear path accessing that information. With = cable I have even less hope, as will never get the modem into the router = (then again DOCSIS 3.1's typically faster speeds and mandatory pie in = the modem might make the situation less dire than on the DSL side). So for ATM based links, I think we can estimate a number of = relevant parameters about encapsulation and an aggregate up- and = down-bandwidth measurement (which alas is not too helpful unless we know = the degree of asymmetry or one of the bandwidth, in both cases we are = likely to know everything a priori anyway). But the current prototype = code I have is really slow (3 hours measurement time with otherwise = quiet home network; ~20 processing) and memory demanding (the ascii ping = traces take up ~260MB) so will not be able to run on the router (also = the current implementation in matlab/octave does not lend itself well = for an embedded platform=85) Best Regards Sebastian >=20 >> The overhead for the particular setup I use was 40 for PPPoE, and 10 = for >> PPPoA. >>=20 >> The default you suggest is a suitable starting point, I suggest. >>=20 >>=20 >> On 04/01/14 18:16, Rich Brown wrote: >>>=20 >>> QUESTION #5: I still don=92t have any great answers for the Link = Layer >>> Adaptation overhead descriptions and recommendations. In an earlier = message, >>> (see >>> = https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914= .html >>> and following messages), Fred Stratton described the overheads = carried by >>> various options, and Sebastian Moeller also gave some useful advice. >>>=20 >>> After looking at the options, I despair of giving people a clear >>> recommendation that would be optimal for their equipment. = Consequently, I >>> believe the best we can do is come up with =93good enough=94 = recommendations >>> that are not wrong, and still give decent performance. >>>=20 >>> In this spirit, I have changed Draft #3 of the =93Setting up SQM=94 = page to >>> reflect this understanding. See >>> = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWr= t_310 >>>=20 >>> ADSL/ATM link: Choose =93ADSL/ATM", and set Per Packet = Overhead to >>> 40 >>> VDSL2 link: Choose =93VDSL=94, and set Per Packet Overhead to = 8 >>> Other kind of link (e.g., Cable, Fiber, Ethernet, other not >>> listed): Choose =93None (default)=94, and set Per Packet Overhead to = 0 >>>=20 >>> NB: I have changed the first menu choice to =93ADSL/ATM=94 and the = second to >>> =93VDSL=94 in the description. I would ask that we change to GUI to = reflect >>> those names as well. This makes it far easier/less confusing to talk = about >>> the options. >>>=20 >>> As always, I welcome help in setting out clear recommendations that = work >>> well for the vast majority of people who try CeroWrt. Thanks. >>>=20 >>> Rich >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >>=20 >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=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