From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8FF2421F2F0 for ; Wed, 28 May 2014 02:39:25 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 9351E406062; Wed, 28 May 2014 02:39:20 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: bloat@lists.bufferbloat.net From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 2014 02:39:20 -0700 Message-Id: <20140528093920.9351E406062@ip-64-139-1-69.sjc.megapath.net> Cc: Hal Murray Subject: Re: [Bloat] ipspace.net: "QUEUING MECHANISMS IN MODERN SWITCHES" X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:39:26 -0000 > in non discarding scheduling total delay is conserved, > irrespective of the scheduling discipline Is that true for all backplane/switching topologies? > The question is if (codel/pie/whatever) AQM makes sense at all for 10G/40G > hardware and higher performance irons? Igress/egress bandwidth is nearly > identical, a larger/longer buffering should not happen. Line card memory is > limited, a larger buffering is defacto excluded. The simplest interesting case is where you have two input lines feeding the same output line. AQM may not be the best solution, but you have to do something. Dropping any packet that won't fit into the buffer is probably simplest. -- These are my opinions. I hate spam.