Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Dave Taht <dave.taht@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] 800gige
Date: Wed, 15 Apr 2020 19:39:13 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.2004151929250.30389@uplift.swm.pp.se> (raw)
In-Reply-To: <CAA93jw5tQvqv-6CR9X+s2Shh9mrhv=k61s8WCtNLH=eLvhpvxA@mail.gmail.com>

On Sat, 11 Apr 2020, Dave Taht wrote:

> The way I've basically looked at things since 25Gbit ethernet was that
> improvements in single stream throughput were dead. I see a lot of
> work on out of order delivery tolerance as an outgrowth of that,
> but... am I wrong?

Backbone ISPs today are built with lots of parallel links (20x100GE for 
instance) and then we do L4 hashing for flows across these. This means a 
single L4 flow is capped at less than 100GE. This is not a huge problem 
but we're always trying to get faster and faster ports for single flow 
(and for other reasons).

We're now going for 100 gigabit/s per lane (it's been going up from 4x2.5G 
for 10GE to 1x10G, then we went for lane speeds of 10G, 25G, 50G and now 
we're at 100G per lane), and it seems the 800GE in your link has 8 lanes 
of that. This means a single L4 flow can be 800GE even though it's in 
reality 8x100G lanes, as a single packet bits are being sprayed across all 
the lanes.

The lane speeds are going up and up, and this relates to PCI-E as well, 
but it's not fast enough to we're going wider as well (think equivalent 
PCI-E x16).

Out the port we're trying to DWDM long-haul transmissions and we're 
getting closer and closer to the shannon limit and we're throwing lots of 
DSP at the problem (the new DSPs are 7nm and they already have 5nm and 3nm 
roadmaps for these DSPs to keep power down).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

  parent reply	other threads:[~2020-04-15 17:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11 23:08 Dave Taht
2020-04-12 16:15 ` David P. Reed
2020-04-15 17:39 ` Mikael Abrahamsson [this message]
     [not found] ` <mailman.1077.1586972355.1241.cerowrt-devel@lists.bufferbloat.net>
2020-04-15 20:57   ` Michael Richardson
2020-04-15 21:08     ` Joel Wirāmu Pauling
2020-04-15 21:35       ` 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/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=alpine.DEB.2.20.2004151929250.30389@uplift.swm.pp.se \
    --to=swmike@swm.pp.se \
    --cc=cerowrt-devel@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