<div dir="ltr"><div>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.<br><br>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.   <a href="https://www.communications.gov.au/what-we-do/internet/competition-broadband/telstras-separation-framework">https://www.communications.gov.au/what-we-do/internet/competition-broadband/telstras-separation-framework</a><br><br></div><div>Back to humans getting in the way of ourselves which is all too common.</div><div><br></div><div>Bob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 2:36 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 14 Feb, 2020, at 12:23 am, David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<br>
> <br>
> The modem clearly is capable of giving congestion control signals to a directly connected Ethernet path (non-wireless), by dropping packets.<br>
<br>
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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br>
<br>
</blockquote></div>