General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: jholland@akamai.com, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] one benefit of turning off shaping + fq_codel
Date: Tue, 27 Nov 2018 11:09:44 -0800	[thread overview]
Message-ID: <CAA93jw5P=WTKjTeG8usPJs4DdRO2juQZ-Pk9sEcJtVv032vy4w@mail.gmail.com> (raw)
In-Reply-To: <20181127103114.3f403d8a@xeon-e3>

On Tue, Nov 27, 2018 at 10:31 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Tue, 27 Nov 2018 18:14:01 +0000
> "Holland, Jake" <jholland@akamai.com> wrote:
>
> > On 2018-11-23, 08:33, "Dave Taht" <dave@taht.net> wrote:
> >     Back in the day, I was a huge fan of async logic, which I first
> >     encountered via caltech's cpu and later the amulet.
> >
> >     https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU
> >
> > ...
> >
> >     I've never really understood why it didn't take off, I think, in part,
> >     it doesn't scale to wide busses well, and that centrally clocked designs
> >     are how most engineers and fpgas and code got designed since. Anything
> >     with delay built into it seems hard for EEs to grasp.... but I wish I
> >     knew why, or had the time to go play with circuits again at a reasonable
> >     scale.
> >
> > At the time, I was told the objections they got were that it uses about 2x the space for the same functionality, and space usage is approximately linear with the chip cost, and when under load you still need reasonable cooling, so it was only considered maybe worthwhile for some narrow use cases.

And the pentultimate cost here was unpredictable and many power
states, hyperthreading (which is looking to die post spectre), and
things like ddpk which spin processors madly to keep up. I always
liked things like

I wish I knew more about what fulcrum did in their switch designs...

everybody knows I'm a fan of the mill cpu which has lots of little
optimizations close to each functional unit (among many other things
using virtual memory internally for everything,
and separating out the PLB (protection level buffer) from the TLB). I
would really like to bring back an era where cpus could context or
security level switch in 5 clocks.

Someday something like that will be built. Til then, the closest chip
to something I'd like to be working on for networks is how the xmos is
designed: https://en.wikipedia.org/wiki/XMOS#xCORE_multicore_microcontrollers
- or https://www.xmos.com/developer/silicon/xcore200-ethernet which
has 1MByte of single-clock sram on it.

"The xCORE architecture delivers, in hardware, many of the elements
that are usually seen in a real-time operating system (RTOS). This
includes the task scheduler, timers, I/O operations, and channel
communication. By eliminating sources of timing uncertainty
(interrupts, caches, buses and other shared resources), xCORE can
provide deterministic and predictable performance for many
applications. A task can typically respond in nanoseconds to events
such as external I/O or timers. This makes it possible to program
xCORE devices to perform hard real-time tasks that would otherwise
require dedicated hardware."

Nobody else's ethernet controllers work this way.

> >
> > I don't really know enough to confirm or deny the claim, and the use cases may have gotten a lot closer to a good match by now, but this was the opinion of at least some of the people involved with the work, IIRC.
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
> With asynchronous circuits there is too much unpredictablity and instability.
> Seem to remember there are even cases where two inputs arrive at once and output is non-determistic.

Yes, that was a big problem... in the 90s... but cpus *were*
successfully designed that didn't do that.

I am the sort of character that is totally willing to toss out decades
of evolution in chip design in order to get better SNR for wireless.
:)

I wish I knew of a mailing list where I could get a definitive answer
on "modern problems with async circuits", or an update on the kind of
techniques the new AI chips were using to keep their power consumption
so low. I'll keep googling.

> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

  reply	other threads:[~2018-11-27 19:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 16:54 Dave Taht
2018-11-14 17:09 ` Mikael Abrahamsson
2018-11-15  0:56   ` David Lang
2018-11-15  3:44     ` Dave Taht
2018-11-23 11:47 ` Pete Heist
2018-11-23 16:26   ` Dave Taht
2018-11-23 16:43     ` Jonathan Morton
2018-11-23 16:48       ` Dave Taht
2018-11-23 17:16         ` Luca Muscariello
2018-11-23 17:27           ` Dave Taht
2018-11-23 17:32             ` Luca Muscariello
2018-11-25 21:14               ` Toke Høiland-Jørgensen
2018-11-26 12:52                 ` Pete Heist
2018-11-26 12:54                   ` Dave Taht
2018-11-26 13:30                     ` Toke Høiland-Jørgensen
2018-11-26 13:26                   ` Toke Høiland-Jørgensen
2018-11-24 11:49     ` Pete Heist
2018-12-05  0:25       ` David Lang
2018-11-27 18:14     ` Holland, Jake
2018-11-27 18:31       ` Stephen Hemminger
2018-11-27 19:09         ` Dave Taht [this message]
2018-11-27 22:07           ` Pete Heist
2018-11-27 22:33             ` Jonathan Morton
2018-11-27 22:36               ` Jonathan Morton
2018-11-28  7:23                 ` [Bloat] hardware diversions Dave Taht
2018-11-27 19:11         ` [Bloat] one benefit of turning off shaping + fq_codel Holland, Jake

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='CAA93jw5P=WTKjTeG8usPJs4DdRO2juQZ-Pk9sEcJtVv032vy4w@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jholland@akamai.com \
    --cc=stephen@networkplumber.org \
    /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