>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, <[email protected]> wrote: >> Fra: Pete Heist <[email protected]> >> - 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 > [email protected] > https://lists.bufferbloat.net/listinfo/cake -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
