Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface

[Bob McMahon <bob.mcmahon@broadcom.com>]

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

I believe this switching path is all transistors on a very low cost chip
where no sw is involved.  I also think some nighthawks have the ability to
disable honoring the pause frames on a per port basis.

The core of such a problem seems to be a 1Gb/s switch port connected to a
25Mb/s one.  I've noticed when my relatives purchased XFINITY home security
services they significantly increased their uplink speeds all for the
security cameras.  So this may be an issue per the lack of structural
separation.
https://www.communications.gov.au/what-we-do/internet/competition-broadband/telstras-separation-framework

Back to humans getting in the way of ourselves which is all too common.

Bob

On Thu, Feb 13, 2020 at 2:36 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 14 Feb, 2020, at 12:23 am, David P. Reed <dpreed@deepplum.com> wrote:
> >
> > The modem clearly is capable of giving congestion control signals to a
> directly connected Ethernet path (non-wireless), by dropping packets.
>
> No - by sending Pause frames back.  It's an increasingly-used method of
> applying back pressure on an Ethernet link, in preference to dropping
> packets.  If it *did* drop packets, you wouldn't get an F grade for bloat.
>
> So the Nighthawk is correctly halting Ethernet output in response to those
> frames (it's probably a function of the NIC hardware or driver), but
> exercises absolutely no control over the queue that builds up as a result.
>
>  - Jonathan Morton
>
>

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