Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: bloat <bloat@lists.bufferbloat.net>,
	 cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] capacity awareness for the deadline scheduler
Date: Mon, 1 Jun 2020 13:35:42 -0700	[thread overview]
Message-ID: <CAA93jw7gUQ49wQHknouJ1NRewsF8L8+JLiXWO5KU4emGO4-ZQQ@mail.gmail.com> (raw)
In-Reply-To: <18883.1591027117@localhost>

On Mon, Jun 1, 2020 at 8:58 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Dave Taht <dave.taht@gmail.com> wrote:
>     > Gradually, people seem to be getting more and more about basic queue theory.
>     > https://lwn.net/SubscriberLink/821578/ef5d913a20977921/
>
> Having skimmed the article, which seems to be mostly about CPU scheduling, I
> have a question.
>
> Does the availability of better *CPU* scheduling make it easier to do better
> TCP pacing?  Maybe that was your entire point?

It wasn't my entire point, it's just that I'm pleased to see more and
more progress in more people more deeply understanding kleinrocks
work.

as one example, pie's default rate estimator tends to go to hell in
the presence of jitter - be it induced by cpu scheduling, offloads,
pulling stuff off the rx ring, or putting it on the tx ring. A fixed
version of pie is documented here:
https://www.sciencedirect.com/science/article/abs/pii/S1389128619313775
. All I knew at the time pie was being developed was that it didn't
work well with hw multiqueue, I was not
aware the rate estimator problem was more general.

it worries me that pie is being naively applied to cable modem tech as
this problem does not show up in simple simulations.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

  reply	other threads:[~2020-06-01 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 21:39 [Cerowrt-devel] " Dave Taht
2020-06-01 15:58 ` [Cerowrt-devel] [Bloat] " Michael Richardson
2020-06-01 20:35   ` Dave Taht [this message]
2020-06-01 16:02 ` Michael Richardson
2020-06-01 20:31   ` 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=CAA93jw7gUQ49wQHknouJ1NRewsF8L8+JLiXWO5KU4emGO4-ZQQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=mcr@sandelman.ca \
    /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