General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave@taht.net>
To: Matthias Tafelmeier <matthias.tafelmeier@gmx.net>
Cc: Bob Briscoe <ietf@bobbriscoe.net>,
	ken@cs.cornell.edu, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] DETNET
Date: Sun, 19 Nov 2017 10:33:02 -0800	[thread overview]
Message-ID: <87a7zirue9.fsf@nemesis.taht.net> (raw)
In-Reply-To: <a86d8ba8-9c4f-ebe9-c4ad-ef1996a8c225@gmx.net> (Matthias Tafelmeier's message of "Sat, 18 Nov 2017 16:38:52 +0100")

Matthias Tafelmeier <matthias.tafelmeier@gmx.net> writes:

> On 11/15/2017 08:31 PM, Dave Taht wrote:
>
>     Nonetheless, it's important to have a debate about where to go to next.
>     Personally I don't think fq_CoDel alone has legs to get (that) much better. 
>
>     The place where bob and I always disconnect is that I care about
> interflow latencies generally more than queuing latencies and prefer to
> have strong incentives for non-queue building flows in the first
> place. This results in solid latencies of 1/flows at your bandwidth. At
> 100Mbit, a single 1500 byte packet takes 130us to deliver, gbit, 13us,
> 10Gbit, 1.3us.
>
> A not necessarily informed enough question to that: couldn't this marking based
> virtual queueuing get extended to a per flow mechanism if the marking loop was
> implemented in an efficient way?

Bob's mechanism splits into 2 queues based on the presence of ecn in the
header. It is certainly possible to do fq with more queues within their
concept. :)

I've tossed fq_codel onto their groups' demo. Which, if you toss any but
their kind of traffic through it, seemed to perform pretty good, and
even with... well, I'd like to see some long RTT tests of their stuff vs
fq_codel.


At the moment, I'm heads down on trying to get sch_cake (
https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ ), maybe
even the "cobalt" branch which has a codel/blue hybrid in it,
upstream.

Mellonox is making available a toolkit for some of their boards, I've
been meaning to take a look at it. ENOTIME.

On the high end, ethernet hardware is already doing the 5 tuple hash
needed for good FQ for us (this is used for sch_fq, fq_codel, and even
more importantly RSS steering), but cake uses a a set associative hash
and some other tricks that would be best also to push into hardware. I'd
love (or rather, an ISP would love) to be able to run 10k+ good shapers
in hardware.

...

At some point next year I'll take a look at detnet. Maybe.

  parent reply	other threads:[~2017-11-19 18:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04 13:45 Matthias Tafelmeier
     [not found] ` <87shdr0vt6.fsf@nemesis.taht.net>
2017-11-12 14:58   ` Matthias Tafelmeier
2017-11-12 19:58     ` Bob Briscoe
2017-11-13 17:56       ` Matthias Tafelmeier
2017-11-15 19:31         ` Dave Taht
2017-11-15 19:45           ` Ken Birman
2017-11-15 20:09             ` Matthias Tafelmeier
2017-11-15 20:16               ` Dave Taht
2017-11-15 21:01                 ` Ken Birman
2017-11-18 15:56                   ` Matthias Tafelmeier
2017-12-11 20:32                   ` Toke Høiland-Jørgensen
2017-12-11 20:43                     ` Ken Birman
2017-11-18 15:38           ` Matthias Tafelmeier
2017-11-18 15:45             ` Ken Birman
2017-11-19 18:33             ` Dave Taht [this message]
2017-11-19 20:24               ` Ken Birman
2017-11-20 17:56                 ` [Bloat] *** GMX Spamverdacht *** DETNET Matthias Tafelmeier
2017-11-20 19:04                   ` Ken Birman
2017-12-17 12:46                     ` Matthias Tafelmeier
2017-12-17 16:06                       ` Ken Birman
2017-11-18 17:55           ` [Bloat] DETNET Matthias Tafelmeier
2017-11-18 19:43             ` Ken Birman
2017-11-18 19:47               ` Ken Birman
2017-11-20 18:32               ` Matthias Tafelmeier

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=87a7zirue9.fsf@nemesis.taht.net \
    --to=dave@taht.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=ietf@bobbriscoe.net \
    --cc=ken@cs.cornell.edu \
    --cc=matthias.tafelmeier@gmx.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