Re: [Rpm] Almost had a dialog going with juniper...

[Dave Taht <dave.taht@gmail.com>]

On Sun, Feb 19, 2023 at 3:34 PM rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:
>
> Their post isn't really about bloat. It's about the discrepancy in i/o
> bw of memory off-chip and on-chip.

The original comment thread was about how the flow queuing aspect of
fq_codel derived algorithms, would leverage on-chip resources better,
and about how VOQs do misbehave today.


>
> My opinion is that the off-chip memory or hybrid approach is a design
> flaw for a serious router mfg.

I concur. I think we need smarter buffering, not more buffering.
Admittedly while the overhead for
10,000 fq_codel'd virtual queues (e.g. 1 million total queue states)
without tuning is presently 64M that needs to live in high speed
memory for that next indirect lookup... it is possible to trim that
down quite a lot.

> The flaw is thinking the links' rates and
> the chip memory i/o rates aren't connected when obviously they are. Just
> go fast as possible and let some other device buffer, e.g. the end host
> or the server in the cloud.

Juniper will hold onto their big buffers are
profitable^H^H^H^H^H^H^H^Hneeded strategy until the bitter end.

>
> Bob
> > https://blog.cerowrt.org/post/juniper/
> >
> > But they deleted the comment thread. It is interesting, I suppose, to
> > see how they frame the buffering problems to themselves in their post:
> > https://www.linkedin.com/pulse/sizing-router-buffers-small-new-big-sharada-yeluri/



-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC