On Wed, Mar 25, 2020 at 8:58 AM Aaron Wood <[email protected]> wrote: > > One other thought I've had with this, is that the apu2 is multi-core, and the > i210 is multi-queue. > > Cake/htb aren't, iirc, setup to run on multiple cores (as the rate limiters > then don't talk to each other). But with the correct tuple hashing in the > i210, I _should_ be able to split things and do two cores at 500Mbps each > (with lots of compute left over). > > Obviously, that puts a limit on single-connection rates, but as the number of > connections climb, they should more or less even out (I remember Dave Taht > showing the oddities that happen with say 4 streams and 2 cores, where it's > common to end up with 3 streams on the same core). But assuming that the > hashing function results in even sharing of streams, it should be fairly > balanced (after plotting some binomial distributions with higher "n" values). > Still not perfect, especially since streams aren't likely to all be > elephants.
We live with imperfect per core tcp flow behavior already. What I wanted to happen was the "list" ingress improvement to become more generally available ( I can't find the lwn link at the moment). It has. I thought that then we could express a syntax of tc qdisc add dev eth0 ingress cake-mq bandwidth whatever, and it would rock. I figured getting rid of the cost of the existing ifb and tc mirred, and having a fast path preserving each hardware queue, then using rcu to do a sloppy allocate atomic lock for shaped bandwidth and merge every ms or so might be then low-cost enough. Certainly folding everything into a single queue has a cost! I was (before money ran out) prototyping adding a shared shaper to mq at one point (no rcu, just There have been so many other things toss around (bpf?) As for load balancing better, google "RSS++", if you must. > On Wed, Mar 25, 2020 at 4:03 AM Toke Høiland-Jørgensen <[email protected]> wrote: >> >> Sebastian Moeller <[email protected]> writes: >> >> > Hi Toke, >> > >> > >> >> On Mar 25, 2020, at 09:58, Toke Høiland-Jørgensen <[email protected]> wrote: >> >> >> >> Aaron Wood <[email protected]> writes: >> >> >> >>> I recently upgraded service from 150up, 10dn Mbps to xfinity's gigabit >> >>> (with 35Mbps up) tier, and picked up a DOCSIS 3.1 modem to go with it. >> >>> >> >>> Flent test results are here: >> >>> https://burntchrome.blogspot.com/2020/03/bufferbloat-with-comcast-gigabit-with.html >> >>> >> >>> tl/dr; 1000ms of upstream bufferbloat >> >>> >> >>> But it's DOCSIS 3.1, so why isn't PIE working? Theory: It's in DOCSIS >> >>> 3.0 >> >>> upstream mode based on the status LEDs. Hopefully it will go away if I >> >>> can >> >>> convince it to run in DOCSIS 3.1 mode. >> >> >> >> I think that while PIE is "mandatory to implement" in DOCSIS 3.1, the >> >> ISP still has to turn it on? So maybe yelling at them will work? (ha!) >> >> >> >>> At the moment, however, my WRT1900AC isn't up to the task of dealing with >> >>> these sorts of downstream rates. >> >>> >> >>> So I'm looking at the apu2, which from this post: >> >>> https://forum.openwrt.org/t/comparative-throughput-testing-including-nat-sqm-wireguard-and-openvpn/44724 >> >>> >> >>> Will certainly get most of the way there. >> >> >> >> My Turris Omnia is doing fine on my 1Gbps connection (although that >> >> hardly suffers from bloat, so I'm not doing any shaping; did try it >> >> though, and it has no problem with running CAKE at 1Gbps). >> > >> > Well, doing local network flent RRUL stress tests indicated that >> > my omnia (at that time with TOS4/Openwrt18) only allowed up to >> > 500/500 Mbps shaping with bi directionally saturating traffic >> > with full MTU-sized packets. So I undirectional CAKE at 1Gbps >> > can work, but under full load, I did not manage that, what did I >> > wrong? >> >> Hmm, not sure I've actually done full bidirectional shaping. And trying >> it now, it does seem to be struggling... >> >> -Toke > > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat -- Make Music, Not War Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
