Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: David Reed <dpreed@reed.com>,
	Jonathan Morton <chromatix99@gmail.com>,
	 "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] trying to make sense of what switch vendors say wrt buffer bloat
Date: Tue, 7 Jun 2016 07:46:46 -0700	[thread overview]
Message-ID: <CAA93jw7=uYPyOAzjonqL244efh2UZ4OL__7nU6tuH7A2-TXdDA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1606071234010.28955@uplift.swm.pp.se>

On Tue, Jun 7, 2016 at 3:46 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Mon, 6 Jun 2016, dpreed@reed.com wrote:
>
>> Even better, it would be fun to get access to an Arista switch and some
>> high performance TCP sources and sinks, and demonstrate extreme bufferbloat
>> compared to a small-buffer switch.  Just a demo, not a simulation full of
>> assumptions and guesses.

In terms of doing this at low cost, we can pretty easily setup a linux
box nowadays that can forward at 10GigE using mellonox hardware.

In terms of finding a (set of) cheap 10GigE capable switches, the
needed investment looks to be in the 20k range to buy one. (?) That is
essentially more than the entire cerowrt hw budget for the past 5
years....

>
> So while it can be rightfully argued that we don't need 100ms worth of
> buffering (here it actually is kind of correct to say "ram is cheap" because
> as soon as you go for offchip RAM, it's now cheap).
>
> So these vendors have two choices:
>
> 1. 8-16MB on-chip buffer.
> 2. External RAM
>
> If you choose the external RAM one, you might as well put a lot of RAM
> there, and give the option to the customer to configure the port buffer
> settings any way they want.
>
> For the on-chip small buffer one, having 80 10GE ports,all sharing 8
> megabyte of buffer (let's say 10 ports are congesting, meaning each port
> gets 800kilobytes of buffer) and each port doing 1.25gigabyte/s of data,
> that's 0.64ms worth of buffer per congested port (I hope I got my math
> right). That is just too little unless you control the TCP stacks of the
> clients, and are just doing low-RTT communication.
>
> So while I'd admit that 100ms worth of FIFO is too much, what needs to
> happen now is to have them configured to do something clever and aiming to
> never have prolonged use of more than a few ms worth of buffer.
>
> It's hard to do AQM with half a millisecond worth of buffer, right?
>
> At least this has been shown by previous generation of datacenter switches
> that had miniscule buffers and ISPs tried to use them and when there were
> microbursts there was uncontrolled packet loss.

Of possible interest, measurementlabs encountered and thoroughly
debugged a microburst problem across their backbones from last year.
This is a good read, although I wish the graphs were more directly
comparable.

https://www.measurementlab.net/publications/SwitchDiscardNotice-Final-20160525.pdf
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

  reply	other threads:[~2016-06-07 14:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 15:29 Eric Johansson
2016-06-06 16:53 ` Toke Høiland-Jørgensen
2016-06-06 17:46   ` Jonathan Morton
2016-06-06 18:37     ` Mikael Abrahamsson
2016-06-06 21:16       ` Ketan Kulkarni
2016-06-07  2:52         ` dpreed
2016-06-07  2:58           ` dpreed
2016-06-07 10:46             ` Mikael Abrahamsson
2016-06-07 14:46               ` Dave Taht [this message]
2016-06-07 17:51             ` Eric Johansson
2016-06-10 21:45               ` dpreed
2016-06-11  1:36                 ` Jonathan Morton
2016-06-11  8:25                 ` Sebastian Moeller
2021-07-02 16:42           ` [Cerowrt-devel] Bechtolschiem Dave Taht
2021-07-02 16:59             ` [Cerowrt-devel] [Bloat] Bechtolschiem Stephen Hemminger
2021-07-02 19:46               ` Matt Mathis
2021-07-07 22:19                 ` [Cerowrt-devel] Abandoning Window-based CC Considered Harmful (was Re: [Bloat] Bechtolschiem) Bless, Roland (TM)
2021-07-07 22:38                   ` Matt Mathis
2021-07-08 11:24                     ` [Cerowrt-devel] " Bless, Roland (TM)
2021-07-08 13:29                       ` Matt Mathis
2021-07-08 14:05                         ` [Cerowrt-devel] " Bless, Roland (TM)
2021-07-08 14:40                         ` [Cerowrt-devel] [Bloat] Abandoning Window-based CC Considered Harmful (was Bechtolschiem) Jonathan Morton
2021-07-08 20:14                           ` David P. Reed
2021-07-08 13:29                       ` Neal Cardwell
2021-07-02 20:28               ` [Cerowrt-devel] [Bloat] Bechtolschiem Jonathan Morton
2016-06-07 22:31 ` [Cerowrt-devel] trying to make sense of what switch vendors say wrt buffer bloat Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA93jw7=uYPyOAzjonqL244efh2UZ4OL__7nU6tuH7A2-TXdDA@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dpreed@reed.com \
    --cc=swmike@swm.pp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox