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

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

On Sun, Feb 19, 2023 at 3:37 PM rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:
>
> A bit off topic, but the AP/client power asymmetry is another design
> flaw similar to bloat.

It makes no sense to broadcast at a watt when the device is nearby. I
think this is a huge, and largely unexplored problem. We tried to
tackle it in the minstrel-blues project but didn't get far enough, and
the rate controllers became too proprietary to continue. Some details
here:

https://github.com/thuehn/Minstrel-Blues

>
> Not sure why nobody is talking about that.

Understanding of the inverse square law is rare. The work we did at
google fiber, clearly showed the chromecast stick overdriving nearby
APs.

https://apenwarr.ca/diary/wifi-data-apenwarr-201602.pdf


> https://www.youtube.com/watch?v=Ey5jVUXSJn4

Haha.

>
> Bob
> > Their post isn't really about bloat. It's about the discrepancy in i/o
> > bw of memory off-chip and on-chip.
> >
> > My opinion is that the off-chip memory or hybrid approach is a design
> > flaw for a serious router mfg. 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.
> >
> > 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/
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm



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