Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "David P. Reed" <dpreed@deepplum.com>
To: "Jonathan Morton" <chromatix99@gmail.com>
Cc: "Dave Taht" <dave.taht@gmail.com>,
	jonathan.kua@deakin.edu.au,
	"Cake List" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Understanding the Achieved Rate Multiplication Effect in FlowQueue-based AQM Bottleneck
Date: Sat, 4 Dec 2021 18:01:50 -0500 (EST)	[thread overview]
Message-ID: <1638658910.996417608@apps.rackspace.com> (raw)
In-Reply-To: <0A6AB0B7-E010-42E3-BAEE-FCBFA5995117@gmail.com>

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


I agree with your broad assessment, Jonathan.
 
The self-interference problem within a host isn't just a network problem. It's a user-space scheduler problem as well.
 
There are lots of interactions between user-space scheduler (in the case of Linux, the "Completely Fair Scheduler" and its quantum, which is set by the HZ variable at boot) and the network stack in the kernel. This interactions have non-trivial effects when mutliple flows are independently created by concurrent processes).
 
Lately, I've been studying, for reasons related to my day job, the complex interactions of timing at sub-millisecond scale among threads and processes on a single system in Linux. I/O driven by threads become highly correlated, and so assuming "independence" among flow timing  is just not a good assumption.
 
The paper observes the results of "dependencies" that couple/resonate.
 
On Friday, December 3, 2021 7:09pm, "Jonathan Morton" <chromatix99@gmail.com> said:



> > On 4 Dec, 2021, at 12:27 am, Dave Taht <dave.taht@gmail.com> wrote:
> >
> >
> https://jonathankua.github.io/preprints/jkua-ieeelcn2021_understanding_ar_preprint-20jul2021.pdf
> >
> > I would love it if somehow the measured effects of chunklets against cake's
> per-host/per flow fq was examined one day.
> 
> I haven't actually measured it, but based on what the above paper says, I can make
> some firm predictions:
> 
> 1: When competing against traffic to the same local host, the performance effects
> they describe will be present.
> 
> 2: When competing against traffic to a different local-network host, the
> performance effects they describe will be attenuated or even entirely absent.
> 
> 3: They noted one or two cases of observable effects of hash collisions in their
> tests with FQ-Codel. These will be greatly reduced in prevalence with Cake, due
> to the set-associative hash function which specifically addresses that phenomenon.
> 
> - Jonathan Morton
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> 

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

  parent reply	other threads:[~2021-12-04 23:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 22:27 Dave Taht
2021-12-04  0:09 ` Jonathan Morton
2021-12-04 18:44   ` Dave Taht
2021-12-04 22:29     ` David P. Reed
2021-12-05  1:20       ` Dave Taht
2021-12-04 23:01   ` David P. Reed [this message]
2021-12-05  1:24     ` Dave Taht
2021-12-07 20:04       ` David P. Reed

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/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1638658910.996417608@apps.rackspace.com \
    --to=dpreed@deepplum.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dave.taht@gmail.com \
    --cc=jonathan.kua@deakin.edu.au \
    /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