[Bloat] one benefit of turning off shaping + fq_codel

[Dave Taht]

On Tue, Nov 27, 2018 at 10:31 AM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> On Tue, 27 Nov 2018 18:14:01 +0000
> "Holland, Jake" <jholland at akamai.com> wrote:
>
> > On 2018-11-23, 08:33, "Dave Taht" <dave at 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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

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