From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>,
"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed
Date: Thu, 26 Apr 2018 17:42:03 +0300 [thread overview]
Message-ID: <79A11608-89FF-4353-822A-8A31D6FAC891@gmail.com> (raw)
In-Reply-To: <51A5A6AB-4B1C-4795-8136-9EB63E59598B@gmx.de>
> I really liked you initial idea to make the threshold when to segment a superpacket based on the duration that packet would hogg the wire/shaper, as that gives an intuitive feel for the worst case inter-flow latency induced. Especially this would allow on many links intermediate sized superpackets to survive fine while turning 64K "oil-tankers" into a fleet of speedboats ;). This temporal threshold would also automatically solve the higher bandwdth cases elegantly. What was the reason to rip that out again?
It probably had something to do with needing to scale that threshold with the number of active flows, which isn't necessarily known at enqueue time with sufficient accuracy to be relevant at dequeue, in order to be able to guarantee a given peak inter-flow induced latency. Unconditional segmentation made the question easy and didn't seem to have very much effect on the CPU (at the link rates we were targeting).
It might still be reasonable to assume the number of active flows won't change *much* between enqueue and dequeue. So then we could set the threshold at, say, half the Codel target divided by the number of active flows plus one.
- Jonathan Morton
next prev parent reply other threads:[~2018-04-26 14:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 20:45 Toke Høiland-Jørgensen
2018-04-26 1:10 ` Ryan Mounce
2018-04-26 1:32 ` Stephen Hemminger
2018-04-26 3:23 ` Dave Taht
2018-04-26 6:39 ` Toke Høiland-Jørgensen
2018-04-26 6:54 ` Ryan Mounce
2018-04-26 7:14 ` Toke Høiland-Jørgensen
2018-04-26 7:19 ` Kevin Darbyshire-Bryant
2018-04-26 7:34 ` Toke Høiland-Jørgensen
2018-04-26 8:43 ` Jonas Mårtensson
2018-04-26 8:55 ` Toke Høiland-Jørgensen
2018-04-26 12:02 ` Jonas Mårtensson
[not found] ` <mailman.301.1524727201.3573.cake@lists.bufferbloat.net>
2018-04-26 7:26 ` Jonathan Morton
2018-04-26 7:43 ` Sebastian Moeller
2018-04-26 14:42 ` Jonathan Morton [this message]
2018-04-26 15:25 ` Sebastian Moeller
2018-04-27 0:17 ` David Lang
2018-04-26 8:16 ` Kevin Darbyshire-Bryant
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=79A11608-89FF-4353-822A-8A31D6FAC891@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
--cc=moeller0@gmx.de \
/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