From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.ord1c.emailsrvr.com (smtp89.ord1c.emailsrvr.com [108.166.43.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9574921F3E6 for ; Thu, 29 May 2014 17:32:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4B1A71805DE; Thu, 29 May 2014 20:32:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.ord1c.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id E189A180547; Thu, 29 May 2014 20:32:06 -0400 (EDT) User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: <30541.1401406850@sandelman.ca> References: <1401048053.664331760@apps.rackspace.com> <1401290405.100110358@apps.rackspace.com> <3eb328c9-05fb-4594-81cc-71e6a623b977@katmail.1gravity.com> <30541.1401406850@sandelman.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----PUNNI98P1XKKJHL3ZJ1W4NQCZKPYNZ" Content-Transfer-Encoding: 8bit From: "David P. Reed" Date: Thu, 29 May 2014 20:32:04 -0400 To: Michael Richardson Message-ID: Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ubiquiti QOS X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:32:08 -0000 ------PUNNI98P1XKKJHL3ZJ1W4NQCZKPYNZ Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Good points... On May 29, 2014, Michael Richardson wrote: > >David P. Reed wrote: >> ECN-style signaling has the right properties ... just like TTL it can > > provide > >How would you send these signals? > >> A Bloom style filter can remember flow statistics for both of these >local > > policies. A great use for the memory no longer misapplied to > > buffering.... > >Well. > >On the higher speed dataflow equipment, the buffer is general purpose >memory, >so reuse like this is particularly possible. > >On routers built around general purpose architectures, the limiting >factor >in performance is often memory throughput; adding memory rarely >increases >total throughput. Packet I/O is generally quiet sequential and so >makes >good use of wide memory data paths and multiple accesses per address >cycle. >Updating of tables such as Bloom filter or any other hash has a big >impact >due to the RMW and random access nature. > >All I'm saying is that quantity of memory is seldom the problem, but >access >to it, is. > >I do like the entire idea; it seems that it has to be implemented at >the >places where the flow converge, which is often in the DSL line card, or >CTMS... > >-- >] Never tell me the odds! | ipv6 mesh >networks [ >] Michael Richardson, Sandelman Software Works | network >architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >rails [ -- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------PUNNI98P1XKKJHL3ZJ1W4NQCZKPYNZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Good points...

On May 29, 2014, Michael Richardson <mcr@sandelman.ca> wrote:

David P. Reed <dpreed@reed.com> wrote:
ECN-style signaling has the right properties ... just like TTL it can
provide

How would you send these signals?

A Bloom style filter can remember flow statistics for both of these local
policies. A great use for the memory no longer misapplied to
buffering....

Well.

On the higher speed dataflow equipment, the buffer is general purpose memory,
so reuse like this is particularly possible.

On routers built around general purpose architectures, the limiting factor
in performance is often memory throughput; adding memory rarely increases
total throughput.   Packet I/O is gener
 ally
quiet sequential and so makes
good use of wide memory data paths and multiple accesses per address cycle.
Updating of tables such as Bloom filter or any other hash has a big impact
due to the RMW and random access nature.

All I'm saying is that quantity of memory is seldom the problem, but access
to it, is.

I do like the entire idea; it seems that it has to be implemented at the
places where the flow converge, which is often in the DSL line card, or
CTMS...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-- Sent from my Android device with K-@ Mail . Please excuse my brevity. ------PUNNI98P1XKKJHL3ZJ1W4NQCZKPYNZ--