<div dir="ltr"><div dir="ltr">On Sun, Mar 29, 2020 at 12:58 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I just finished doing my first openwrt build in a couple years. (with<br>
AQL) Trying to summon up the moxie to try it. Found my soldiering iron<br>
and usb to serial interfaces....<br></blockquote><div><br></div><div>That's kept me from rolling my own...  I have the interfaces, but not the energy to deal with the troubleshooting.  I think I still have an old WNDR3700 in a box somewhere that I could prep as a backup, but I'd rather not go through the hassle.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Mar 25, 2020 at 8:58 AM Aaron Wood <<a href="mailto:woody77@gmail.com" target="_blank">woody77@gmail.com</a>> wrote:<br>
><br>
> One other thought I've had with this, is that the apu2 is multi-core, and the i210 is multi-queue.<br>
><br>
> 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).<br>
<br>
A good test might be sch_mq + cake bandwidth whatever for each hw<br>
queue. irqbalancing also may or may not help.<br></blockquote><div><br></div><div>Bandwidth = 1Gbps or 500Mbps?  (I was thinking 500Mbps for that test setup).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> 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.<br>
<br>
One reason why we are seeing "tcp rack" pushed so hard is due to cable<br>
modems having multiple channels, and thus ooo packets are probable<br>
when you try to push a stream across those channels.<br></blockquote><div><br></div><div>I don't know anything about the channels and how they're bonded.  separate packets on each, or symbols that are spread across all the channels that are used to construct a packet in less time..?  I'd expect to see more out of order packets than I do, if they were using them all separately.  But then none of the tests really do single-stream gigabit.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Me, I'm reasonably confident we've hit the age of "peak bandwidth" for<br>
most things at up/dl rates above 40Mbit.<br></blockquote><div><br></div><div>Very little of what I do gets to high (>50Mbps) rates.  But those that do, I'm glad it's there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
And in the real world at home, a couple hash collissions and unequal<br>
distribution really don't matter for real traffic.<br>
</blockquote></div></div>