From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7FBBB21F205 for ; Sat, 24 May 2014 10:31:52 -0700 (PDT) Received: from hms-beagle.home.lan ([217.86.112.166]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M9bYB-1X1DIo1BbL-00D2oG; Sat, 24 May 2014 19:31:49 +0200 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: Sat, 24 May 2014 19:31:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76D18B75-FD0C-48DA-8DEE-E34B6A49AFFC@gmx.de> References: To: "R." X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:o/+gMkwiELirXUkSVD7U9KV43amvNEzOSkc50A2+QgJnB0iFsSa hjeEZkmoptfjVVFaMSvnwwZo6W9DwH20qk44bbfwFimRD7GZwjI+6tisPecmnh7lVm9reja m1thls/DmGc2dnKORlpwDk+ghTbGBpjUbG1d5klAp2Vyly+7bgpCcBl026Lk3ohJfi9Qd8f qKXUszkFRYXjvkBQyTEZQ== Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. 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: Sat, 24 May 2014 17:31:52 -0000 Hi R, hi List, On May 24, 2014, at 16:12 , "R." wrote: >>> I should point out that another issue with deploying fq_codel widely = is that it requires an accurate measurement (currently) of the providers = bandwidth. >=20 > Pardon my noobiness, but is there a technical obstacle that prevents > the creation of a user-triggered function on the router side that > measures the provider's bandwidth? >=20 > Function, when (luci-gui?) triggered, would: >=20 > 1. Ensure that internet connectivity is present. > 2. Disconnect all clients. > 3. Engage in DL and UL on a dedicated web server, measure stats and > straight up use them in fq_codel -- or suggest them in appropriate > QoS-gui user-boxes. >=20 > Further, this function could be auto-scheduled or made enabled on > router boot up. >=20 > I must be missing something important which prevents this. What is it? Well, I see a couple of challenges that need to be overcome = before this could work.=20 In your step 3 you touch the issue of measuring the current stats; and = somehow what is trickier than one would think: 1) what to measure precisely, a "dedicated web server" sounds like a = great idea, but who is dedicating it and where is it located relative to = the link under test? Rich Brown has made a nice script to measure current throughput = and give an estimate on the effect of link saturation on latency (see = betterspeedtest.sh from = https://github.com/richb-hanover/CeroWrtScripts), but using this from = Germany gives: 2014-05-24 15:44:47 Testing against demo.tohojo.dk with 5 simultaneous = sessions while pinging gstatic.com (60 seconds in each direction) Download: 12.06 Mbps Upload: 1.99 Mbps against a server in Europe, but: Download: 10.42 Mbps Upload: 1.85 Mbps against a server on the east side of the USA. So the router would need = to select a close-by server. Sites as speedtest.net offer this kind of = server selection by proximity but do not have a very reliable way to = load the link and do not measure the effect of link saturation on the = latency=85 but the whole idea is to find the highest bandwidth that foes = not cause indecent increase of latency under load. (Also speed tests are = quite stereotypic in observable behavior and length so some ISPs special = case these to look good; but that is a different kettle of fish=85) Note that there is also the question where one would like to = measure the linkspeed; for example for DSL there is the link to the = DSLAM, the link from the DSLAM to the next network node, sometimes a PPP = link to a remote BRAS system (that might throttle the traffic). All of = these can be the bottlenecks of the ISP connection (depending on = circumstances). My take is that one would like to look at the link = between modem and DSLAM as the bottleneck, but the opinions differ (and = then there is cable with its shared first segment...).=20 2) Some links have quite peculiar properties that are hard to deduce = from quick speed tests. For example ATM based ADSL links (this includes = all ADSL1, ADSL2 and to my knowledge all existing ADSL2+ links) will = show a packetize dependent link speed. In short ATM uses an integer = number of 48 byte cells to transport each packet, so worst case it adds = 47 bytes to the payload for small packet that can effectively double the = size of the packet on the wire, or stared differently half the link = speed for packets of that size. (Note thanks to the work of Jesper = Brouer and Russel Stuart the linux kernel can take care of that issue = for you, but you need to tell the kernel explicitly.) 3) many links actually do not have a constant wire speed available. For = docsis (basically cable) the local segment is shared between many users = and transmit timeslots are shared between requestors, giving effectively = slower links during peak hours. For DSL a resync between DSLAM and modem = can (significantly) change the negotiated speed; something cerowrt does = not get any notice of=85 I guess buffer bloat mitigation needs to move into the modems = and DSLAMs to get rid of the bandwidth guessing game. For cable at least = the modems are getting better (thanks to PIE being part of the docsis = 3.1? standard), but for DSL I do not think there is any generic solution = on the horizon=85 Best Regards Sebastian > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel