From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vsmta18-2.nsc.no (vip22scan.telenor.net [148.123.15.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DFB4D3B29E for ; Wed, 3 May 2017 01:59:55 -0400 (EDT) Received: from [153.110.251.168] ([153.110.251.168:49555] helo=ilp-smtp02.man.cosng.net) by vsmta18-2.nsc.no (envelope-from ) (ecelerity 3.6.22.53981 r(Core:3.6.22.0)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id C9/09-08040-9D179095; Wed, 03 May 2017 07:59:54 +0200 Received: from TNS-SKO-24-201.corp.telenor.no (TNS-SKO-24-201.corp.telenor.no [10.179.59.69]) by ilp-smtp02.man.cosng.net (Postfix) with ESMTP id CC5981FCBB; Wed, 3 May 2017 07:59:53 +0200 (CEST) Received: from TNS-SKO-24-208.corp.telenor.no (10.179.59.76) by TNS-SKO-24-201.corp.telenor.no (10.179.59.69) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 May 2017 07:59:53 +0200 Received: from TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6]) by TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6%12]) with mapi id 15.00.1178.000; Wed, 3 May 2017 07:59:53 +0200 From: To: CC: Thread-Topic: [Cake] Recomended HW to run cake and fq_codel? Thread-Index: AQHSw3QWlLDEM2lQwEWHw0Bwy0PLuKHiGDmL Date: Wed, 3 May 2017 05:59:53 +0000 Message-ID: <1493791193941.83458@telenor.com> References: , <7B914FA7-38A6-4113-9B2C-D6246873676A@gmail.com> In-Reply-To: <7B914FA7-38A6-4113-9B2C-D6246873676A@gmail.com> Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.181.50.8] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SCAN_VERDICT: inbox Subject: Re: [Cake] Recomended HW to run cake and fq_codel? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 05:59:56 -0000 > Fra: Pete Heist =0A= > - As for low bandwidth, in my experience AQM works great on low bandwidth= ADSL. A few years ago I=0A= > used fq_codel at a campground to shape a 0.5 / 5 Mbps ADSL connection. Wi= th up to 130 people in the=0A= > camp, it was a disaster before fq_codel, where one person saturating eith= er the up or downstream =0A= > could easily cause 600+ ms of induced latency. fq_codel could keep that t= o 40-50 ms under load, =0A= >enough to make it usable for web browsing, at least, and Cake does better.= =0A= =0A= Thats encouraging! =0A= =0A= =0A= > It=92s an interesting question: what can be done as an ISP? Essentially = it boils down to the fundamentals =0A= > of deploying AQM- finding where the queues are forming and placing fq_cod= el or Cake at the =0A= > bottleneck links, preferring =93hardware=94 queue management like BQL or = in the case of WiFi the ath9k=92s =0A= > driver in LEDE, over soft rate limiting, where possible. When soft rate l= imiting, the rate limiting strategy =0A= > and chosen rate are the most CPU intensive and finicky parts of deploying= AQM.=0A= =0A= What I see as short term posibiliteis for us as ISP's is to push our vendor= s to include this as a part of the feature set. We also could do better wi= th the maketing. Lets steal an idea from the Video area. HD is often writ= ten as 1080P@60. Why not do the same for internet speed? 60M@80ms. Where= the @80ms would be the larges latency in either direction that queue manag= ement would introduce? (This of cource introduces the risk of artificialy = tuning the @xxms to low and ending up with strict policing)=0A= =0A= =0A= > - I don't understand why ADSL modem vendors don=92t just bake BQL-like fu= nctionality right into their =0A= > devices so they can ship AQM without the need for soft rate limiting. AQM= is so effective on ADSL's =0A= > upstream that it seems it would just make a lot of sense. For that matter= , why not on the DSLAM as well =0A= > to shape the customer=92s downstream, if that=92s also a bottleneck?=0A= =0A= I think most ISP's handle shaping on the BRAS level rather than on the DSLA= M, as DSLAM's in general have very limited shaping/qos capabilites.=0A= =0A= Regarding CPEs, to be fair, up coming devices from Intel (Lantiq) will more= or less do away with HW accellerators and do everything in software. Then= the vendors are a lot more free to implement better shapeing strategies.= =0A= =0A= The trade shows and all sales pitches focuses mostly on next gen stuff. Th= ere are comparatively very little recources dedicated to ADSL, where the be= st schedulers is most needed. =0A= =0A= =0A= -Erik=