Bob -
I think it is great that Cisco has been looking at controlling buffer size in datacenters. However, I'm actually quite skeptical of the analysis here.
I think what is going on is that operating system scheduling delays (typical Linux scheduling of ACK packet generation for the TCP stack
With full respect to open source projects like OpenWRT, I think from an
energy, performance & going forward perspective the AP forwarding plane
will be realized by "transistor engineers." This makes the awareness around
bloat by network engineers needed even more because those design cycles
take
Well, we've all been yammering for many years, and the message is
getting through. Yes, at this point, changing the message to be more
directed at engineers than users would help, and to this day, I don't
know how to get to anyone in the
C suite, except through the complaints of their kids. Jim
> 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
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
On Tue, Oct 11, 2022 at 9:58 AM Bob McMahon via Rpm
wrote:
>
> > Saturate a link in both directions simultaneously with multiple greedy
> > flows while measuring load-dependent latency changes for small isochronous
> > probe flows.
>
> This functionality is released in iperf 2.1.8 per the
> 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
