Re: [Cake] [Rpm] [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Rich Brown via Cake]

> On Oct 11, 2022, at 1:05 PM, Bob McMahon  wrote:
> 
> I agree that bufferbloat awareness is a good thing. The issue I have is the 
> approach - ask consumers to "detect it" and replace a device with a new one, 
> that may or may not, meet all the needs of the users.
> 
> Better is that network engineers "design bloat out" from the beginning 
> starting by properly sizing queues to service jitter, and for WiFi, to also 
> enable aggregation techniques that minimize TXOP consumption.

The Yes, but... part of my answer emphasizes awareness. How are the network 
engineers going to know it's worth the (minor) effort of creating 
properly-sized queues?

There are two fronts to attack:

- Manufacturers - This video is a start on getting their customers to use these 
responsiveness test tools and call the support lines.

- Hardware (especially router) reviewers - It kills me that there is radio 
silence whenever I ask a reviewer if they have ever measured 
latency/responsiveness.  (BTW: Has anyone heard from Ben Moskowitz from 
Consumer Reports? We had a very encouraging phone call about a year ago, and 
they were going to get back to us...)

Rich


> Bob
> 
> On Tue, Oct 11, 2022 at 6:57 AM Rich Brown  <mailto:richb.hano...@gmail.com>> wrote:
> 
> 
>> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm > <mailto:r...@lists.bufferbloat.net>> wrote:
>> 
>> > I think conflating bufferbloat with latency misses the subtle point in that
>> > bufferbloat is a measurement in memory units more than a measurement in
>> > time units.
> 
> Yes, but... I am going to praise this video, even as I encourage all the 
> techies to be sure that they have the units correct.
> 
> I've been yammering about the evils of latency/excess queueing for 10 years 
> on my blog, in forums, etc. I have not achieved anywhere near the notoriety 
> of this video (almost a third of a million views).
> 
> I am delighted that there's an engaging, mass-market Youtube video that makes 
> the case that bufferbloat even exists. 
> 
> Rich
> 
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Rich Brown via Cake]

> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm  
> wrote:
> 
> > I think conflating bufferbloat with latency misses the subtle point in that
> > bufferbloat is a measurement in memory units more than a measurement in
> > time units.

Yes, but... I am going to praise this video, even as I encourage all the 
techies to be sure that they have the units correct.

I've been yammering about the evils of latency/excess queueing for 10 years on 
my blog, in forums, etc. I have not achieved anywhere near the notoriety of 
this video (almost a third of a million views).

I am delighted that there's an engaging, mass-market Youtube video that makes 
the case that bufferbloat even exists. 

Rich___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] Update Cake page on bufferbloat.net?

[Rich Brown]

> On Nov 3, 2017, at 2:59 PM, Dave Taht  wrote:

>> I saw a blog posting that was enthusing about codel/fq_codel, and I was 
>> moved to
>> respond that the state of the art was now cake.
> 
> where?

This article (https://www.pcmech.com/article/bufferbloat-fix-slow-network/ 
) is a pretty 
sub-standard explanation of bufferbloat. But I didn't want to come across as 
the "smartest (smart-ass) guy in the room"

My plan was to gently correct the worst errors/misperceptions ("it's the 
bottleneck, stupid") and say that the state of the art had moved ahead, even of 
fq_codel, then point to the Cake page on the site.

>> But I looked at the Cake page on Bufferbloat.net  
>> and wonder if everything there
>> is true, or whether it would be good to update
>> it. https://www.bufferbloat.net/projects/codel/wiki/Cake/ 
>> 
> 
> It's pretty much true.

Good. I will try this weekend to organize that info into a page that would 
serve well readers like those from the pcmech.com  site 
who're new to the subject, and curious about Cake/Bufferbloat.

Rich___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake