From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] known buffer sizes on switches
Date: Sun, 25 Nov 2018 07:44:33 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1811250736390.14216@uplift.swm.pp.se> (raw)
In-Reply-To: <CAA93jw7i+4zX+R9Pr8qpPSnzbUCvuOp4hJjnFQ2nr=P0c4_EMg@mail.gmail.com>
On Sat, 24 Nov 2018, Dave Taht wrote:
> https://people.ucsc.edu/~warner/buffer.html
Nice resource, thanks.
If someone wonders why things look the way they do, so it's all about
on-die and off-die memory. Either you use off-die or on-die memory, often
SRAM which requires 6 gates per bit. So spending half a billion gates
gives you ~10MB buffer on-die. If you're doing off-die memory (DRAM or
similar) then you'll get the gigabytes of memory seen in some equipment.
There basically is nothing in between. As soon as you go off-die you might
as well put at least 2-6 GB in there.
Also, off-die memory takes IO capacity. A forwarding chip might have 4
"sides" with I/O lanes sets. If you put it in a 1RU device with no buffer,
you can connect ports to all of the lanes. This gives you a very high port
density low buffer size device and a very good price point.
Now, if you want more buffer and more route memory (taking one "side"
each) plus connecting it to a backplane (another side), you now only have
a single "side" left for ports. This is why high route-count, high buffer,
modular switches are so much more expensive compared low-route,
low-buffer, fixed configuration ones.
Above is principle, there are of course combinations and optimizations to
be made so not all devices adhere exactly to the above.
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2018-11-25 6:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-24 23:29 Dave Taht
2018-11-25 6:44 ` Mikael Abrahamsson [this message]
2018-11-28 16:32 Bruno George Moraes
2018-11-28 16:55 ` Dave Taht
2018-11-28 18:25 ` Dave Collier-Brown
2018-11-28 18:26 ` David Collier-Brown
2018-11-28 19:02 ` Dave Taht
2018-11-28 20:34 ` David Collier-Brown
2018-11-29 2:33 ` Dave Taht
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1811250736390.14216@uplift.swm.pp.se \
--to=swmike@swm.pp.se \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/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