Re: [Cake] Recomended HW to run cake and fq_codel?

[Dave Taht <dave.taht@gmail.com>]

>What I see as short term posibiliteis for us as ISP's is to push our vendors to include this as a part of the feature set.  We also could do >better with the maketing.  Lets steal an idea from the Video area.  HD is often written 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 management would introduce?  (This >of cource introduces the risk of artificialy tuning the @xxms to low and ending up with strict policing)

I like this.

900M @ 1.2ms. Taking the 99th percentile from:

http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_cake_950mbit/rrul_torrent-ping_cdf.svg

Since this is a measure of flow switching time:

950Mbit @ 1.2 "FQ"

better, I think, scaled by a reference to pifo on the same test and
test conditions,
(8ms/1.2ms in this case)

http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_pfifo_950mbit/rrul_torrent-ping_cdf.svg

cake: XMbit @ 6.666 FQ!



On Tue, May 2, 2017 at 10:59 PM,  <erik.taraldsen@telenor.com> wrote:
>> Fra: Pete Heist <peteheist@gmail.com>
>> - As for low bandwidth, in my experience AQM works great on low bandwidth ADSL. A few years ago I
>> used fq_codel at a campground to shape a 0.5 / 5 Mbps ADSL connection. With up to 130 people in the
>> camp, it was a disaster before fq_codel, where one person saturating either the up or downstream
>> could easily cause 600+ ms of induced latency. fq_codel could keep that to 40-50 ms under load,
>>enough to make it usable for web browsing, at least, and Cake does better.
>
> Thats encouraging!
>
>
>>  It’s an interesting question: what can be done as an ISP? Essentially it boils down to the fundamentals
>> of deploying AQM- finding where the queues are forming and placing fq_codel or Cake at the
>> bottleneck links, preferring “hardware” queue management like BQL or in the case of WiFi the ath9k’s
>> driver in LEDE, over soft rate limiting, where possible. When soft rate limiting, the rate limiting strategy
>> and chosen rate are the most CPU intensive and finicky parts of deploying AQM.
>
> What I see as short term posibiliteis for us as ISP's is to push our vendors to include this as a part of the feature set.  We also could do better with the maketing.  Lets steal an idea from the Video area.  HD is often written 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 management would introduce?  (This of cource introduces the risk of artificialy tuning the @xxms to low and ending up with strict policing)
>
>
>> - I don't understand why ADSL modem vendors don’t just bake BQL-like functionality right into their
>> devices so they can ship AQM without the need for soft rate limiting. AQM is so effective on ADSL's
>> upstream that it seems it would just make a lot of sense. For that matter, why not on the DSLAM as well
>> to shape the customer’s downstream, if that’s also a bottleneck?
>
> I think most ISP's handle shaping on the BRAS level rather than on the DSLAM, as DSLAM's in general have very limited shaping/qos capabilites.
>
> 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.
>
> The trade shows and all sales pitches focuses mostly on next gen stuff.  There are comparatively very little recources dedicated to ADSL, where the best schedulers is most needed.
>
>
> -Erik
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619