Interesting, sounds like a good data point for the ECN debate. I wonder if that 
pathology happens at lower flow counts.

I’ve been getting into FreeNet’s backhaul. Four of their backhaul links, the 
orange lines in the following map, are licensed spectrum full-duplex 100Mbit 
wireless links (not sure what tech, I’ll ask). I’ve so far not witnessed any 
bloat in these links because they seem to be over-provisioned based on the 
rates of the CPE connections, although that may change as AC is increasingly 
deployed.

http://mapa.czfree.net/#lat=50.76176199690661&lng=15.06277084350586&zoom=13&autofilter=1&type=satellite&geolocate=98%7C114%7C111%7C117%7C109%7C111%7C118%7C115%7C107%7C97&node=6101&aponly=1&bbonly=1&actlink=1&actnode=1&tilt=0&heading=0&;
 
<http://mapa.czfree.net/#lat=50.76176199690661&lng=15.06277084350586&zoom=13&autofilter=1&type=satellite&geolocate=98|114|111|117|109|111|118|115|107|97&node=6101&aponly=1&bbonly=1&actlink=1&actnode=1&tilt=0&heading=0&>

Active flow counts appear to be in the tens sometimes, probably not hundreds 
very often, from what I’ve witnessed so far...

> On Aug 30, 2018, at 8:24 PM, Dave Taht <dave.t...@gmail.com> wrote:
> 
> This version does indeed work against net-next. I managed to break
> myself because I'd been fiddling with flows 32 in some cases, and my
> version
> returns ENOTSUPP for that which sqm doesn't catch... and ohhh....
> boy... htb with a 1000 packet fifo buffer fallback... SUCKS! :)
> 
> As for profiling, once again I found myself distracted by the ecn
> debate. Fitting ecn 500 flows through a 100mbit bottleneck results in
> 1300 packets outstanding
> 26 flows that can't start (presumably due to ecn fall back), and
> without ecn, 450 packets outstanding 3 flows that can't start.
> 
> On Wed, Aug 29, 2018 at 7:23 AM Dave Taht <dave.t...@gmail.com> wrote:
>> 
>> I'm presently compiling against net-next.
>> On Wed, Aug 29, 2018 at 1:12 AM Pete Heist <p...@heistp.net> wrote:
>>> 
>>> 
>>>> On Aug 29, 2018, at 3:04 AM, Dave Taht <dave.t...@gmail.com> wrote:
>>>> 
>>>> Anyway, this should be a drop in replacement (presently) for fq_codel,
>>>> that compiles out of tree and rips out almost everything I don't like.
>>>> 
>>>> https://github.com/dtaht/fq_codel_fast
>>> 
>>> Cool…I’d give it a quick run but it doesn’t compile for me (attached). 
>>> Kernel version?
>>> 
>>>> I think the tc filter thing really hurt us in cake.
>>> 
>>> It would be interesting to see how much. Jon also expressed concern and I’d 
>>> been meaning to try some benchmarks before and after that change…
>>> 
>> 
>> 
>> --
>> 
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
> 
> 
> 
> -- 
> 
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Reply via email to