General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Benjamin Cronce <bcronce@gmail.com>
To: "Dave Täht" <dave@taht.net>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Hardware upticks
Date: Tue, 5 Jan 2016 15:36:10 -0600	[thread overview]
Message-ID: <CAJ_ENFHA++fSosEY5RDR=82H5XdkQ8P31Nhksrq7OA_Ds_EBZg@mail.gmail.com> (raw)
In-Reply-To: <568C1209.5050403@taht.net>

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

On Tue, Jan 5, 2016 at 12:57 PM, Dave Täht <dave@taht.net> wrote:

>
>
> On 1/5/16 10:27 AM, Jonathan Morton wrote:
> > Undoubtedly.  But that beefy quad-core CPU should be able to handle it
> > without them.
>
> Sigh. It's not just the CPU that matters. Context switch time, memory
> bus and I/O bus architecture, the intelligence or lack thereof of the
> network interface, and so on.
>
> To give a real world case of stupidity in a hardware design - the armada
> 385 in the linksys platform connects tx and rx packet related interrupts
> to a single interrupt line, requiring that tx and rx ring buffer cleanup
> (in particular) be executed on a single cpu, *at the same time, in a
> dedicated thread*.
>
> Saving a single pin (which doesn't even exist off chip) serializes
> tx and rx processing. DUMB. (I otherwise quite like much of the marvel
> ethernet design and am looking forward to the turris omnia very much)
>
> ...
>
> Context switch time is probably one of the biggest hidden nightmares in
> modern OOO cpu architectures - they only go fast in a straight line. I'd
> love to see a 1ghz processor that could context switch in 5 cycles.
>

Seeing that most modern CPUs take thousands to tens of thousands of cycles
to switch, 5 is similar to saying "instantly". Some of that overhead is
shooting down the TLB and many layers of cache misses. You can't have
different virtual memory space and not take some large switching overhead
without devoting a lot of transistors to massive caches. And the larger the
caches, the higher the latency.

Modern PC hardware can use soft interrupts to reduce hardware interrupts
and context switching. My Intel i350 issues a steady about 150 interrupts
per second per core regardless the network load, while maintaining tens of
microsecond ping times.

I'm not sure what they could do with custom architectures, but there will
always be an issue with context switching overhead, but they may be able to
cache a few specific contexts knowing that the embedded system will rarely
have more than a few contexts doing the bulk of the work.


>
> Having 4 cores responding to interrupts masks this latency somewhat
> when having multiple sources of interrupt contending... (but see above -
> you need dedicated interrupt lines per major source of interrupts for
> it to work)
>
> and the inherent context switch latency is still always there. (sound
> cheshire's rant)
>
> The general purpose "mainstream" processors not handling interrupts well
> anymore is one of the market drivers towards specialized co-processors.
>
> ...
>
> Knowing broadcom, there's probably so many invasive offloads, bugs
> and errata in this new chip that 90% of the features will never be
> used. But "forwarding in-inspected, un-firewalled, packets in massive
> bulk so as to win a benchmark race", ok, happy they are trying.
>
> Maybe they'll even publish a data sheet worth reading.
>
> >
> > - Jonathan Morton
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4394 bytes --]

  parent reply	other threads:[~2016-01-05 21:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05  6:37 Jonathan Morton
2016-01-05 17:42 ` Aaron Wood
2016-01-05 18:27   ` Jonathan Morton
2016-01-05 18:57     ` Dave Täht
2016-01-05 19:29       ` Steinar H. Gunderson
2016-01-05 19:37         ` Dave Täht
2016-01-05 20:13           ` David Collier-Brown
2016-01-05 20:27           ` Stephen Hemminger
2016-01-05 21:10             ` Jonathan Morton
2016-01-05 23:20             ` Steinar H. Gunderson
2016-01-05 23:17           ` Steinar H. Gunderson
2016-01-05 21:36       ` Benjamin Cronce [this message]
2016-01-06  0:01         ` Steinar H. Gunderson
2016-01-06  0:06           ` Stephen Hemminger
2016-01-06  0:22             ` Steinar H. Gunderson
2016-01-06  0:53               ` Stephen Hemminger
2016-01-06  0:55                 ` Steinar H. Gunderson
2016-01-06  1:22                   ` Stephen Hemminger
2016-01-06  6:18               ` Jonathan Morton

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='CAJ_ENFHA++fSosEY5RDR=82H5XdkQ8P31Nhksrq7OA_Ds_EBZg@mail.gmail.com' \
    --to=bcronce@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave@taht.net \
    /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