Re: [Bloat] Still seeing bloat with a DOCSIS 3.1 modem

[Aaron Wood <woody77@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]

On Sun, Mar 29, 2020 at 12:58 PM Dave Taht <dave.taht@gmail.com> wrote:

> 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....
>

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.


> On Wed, Mar 25, 2020 at 8:58 AM Aaron Wood <woody77@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.
>

Bandwidth = 1Gbps or 500Mbps?  (I was thinking 500Mbps for that test setup).


> > 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.
>

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.


> Me, I'm reasonably confident we've hit the age of "peak bandwidth" for
> most things at up/dl rates above 40Mbit.
>

Very little of what I do gets to high (>50Mbps) rates.  But those that do,
I'm glad it's there.


> And in the real world at home, a couple hash collissions and unequal
> distribution really don't matter for real traffic.
>

[-- Attachment #2: Type: text/html, Size: 3960 bytes --]