I just finished doing my first openwrt build in a couple years. (with AQL) Trying to summon up the moxie to try it. Found my soldiering iron and usb to serial interfaces....
On Wed, Mar 25, 2020 at 8:58 AM Aaron Wood <wood...@gmail.com> 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). A good test might be sch_mq + cake bandwidth whatever for each hw queue. irqbalancing also may or may not help. > 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. One reason why we are seeing "tcp rack" pushed so hard is due to cable modems having multiple channels, and thus ooo packets are probable when you try to push a stream across those channels. Me, I'm reasonably confident we've hit the age of "peak bandwidth" for most things at up/dl rates above 40Mbit. And in the real world at home, a couple hash collissions and unequal distribution really don't matter for real traffic. > > On Wed, Mar 25, 2020 at 4:03 AM Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> Sebastian Moeller <moell...@gmx.de> writes: >> >> > Hi Toke, >> > >> > >> >> On Mar 25, 2020, at 09:58, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> >> >> Aaron Wood <wood...@gmail.com> 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 > Bloat@lists.bufferbloat.net > 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 Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
