Cool, well I for one would like to see the APU be able to handle higher speeds, for FreeNet’s backhaul, at least. Although frankly, I’ve not definitively witnessed any significant bloat in their backhaul yet with production traffic.
A good number of their routers are still ALIX (https://www.pcengines.ch/alix2d2.htm <https://www.pcengines.ch/alix2d2.htm>), all of which are on an upgrade list. These don’t do hfsc + sfq on kernel 2.6.26 much beyond about 70 Mbit. Not a problem to focus on… :) > On Sep 4, 2018, at 11:16 PM, Dave Taht <dave.t...@gmail.com> wrote: > > my guess is that burst and cburst should scale roughly as a function > of the bytes that can fit into 1ms. > On Tue, Sep 4, 2018 at 2:14 PM Dave Taht <dave.t...@gmail.com> wrote: >> >> making htb's cburst and burst parameters 64k gets the APU2 up to >> where it can shape 900mbits. 3 ksoftirq handlers start getting cpu >> time, and we end up 54% idle to achiefe that. >> >> I should really go around running my own old code. I was deeply >> involved in sqm when we still had to run at sub 200mbit levels. since >> then it's been >> mostly tbf (burst 64k) + fq_codel or cake, and me ignoring various bug >> reports about it not scaling well enough at higher rates. >> On Tue, Sep 4, 2018 at 12:59 PM Dave Taht <dave.t...@gmail.com> wrote: >>> >>> less than scientifically (via monitoring top) - on the apu2 >>> >>> 100Mbit sqm (htb + fq_codel) >>> >>> fq_codel_mainline | fq_codel_fast >>> idle 78.8 | 83.5 | >>> si 20 | 16.1 | >>> >>> Yea! But: >>> >>> 900Mbit sqm (htb + fq_codel) >>> >>> fq_codel_mainline | fq_codel_fast >>> idle 74.4 | 74.4 | >>> si 25 | 25.1 | >>> >>> Here: completely bottlenecked on ksoftirqd - and I only get 340Mbits >>> out of the 900mbit setting. quantum 96k and burst of 15000. Haven't >>> fiddled with higher values yet...
_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
