CoDel AQM discussions
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>
Subject: Re: [Codel] The next slice of cake
Date: Sun, 22 Mar 2015 10:39:30 +0100	[thread overview]
Message-ID: <B6540AAC-023D-433B-92B6-B435AA165874@gmx.de> (raw)
In-Reply-To: <CAA93jw4PZ2ARfbeVhoGJTXodu1qy+q11W-Pug3P5OLd=feTzkg@mail.gmail.com>

Hi Dave, hi Jonathan,

On Mar 21, 2015, at 17:09 , Dave Taht <dave.taht@gmail.com> wrote:

> In terms of a cake feature request...
> 
> fq_codel has a maximum number of packets limit, which is set very
> large (10000) to accommodate 10GigE. It is arbitrarily patched down in
> openwrt (1000), and reduced still further by the sqm-scripts (also
> arbitrarily), to reduce the impact of a packet flood on machines with
> very little memory.
> 
> I would like cake to have a byte limit instead. Now, per packet
> overhead in linux is very high, something like 256 extra bytes per
> packet (4x1 vs the smallest size). However, a packet limit can be much
> harder on memory than that - overhead be as large as 64k per "packet"
> on TSO/GSO enabled systems, (dynamic range of 1x1000!), vs using a
> byte limit which would only have issues with lots of small packets.

	I could be out to lunch here, as usual,;but I argue the byte limit should include the kernel overhead (could this be based on skb->truesize) as this is what cunts against real memory. My assumption here is that in normal operation we rarely/never get queues to fill up to the limit anyways (as tho would turn the queue into tail-drop effectively), but if we do we really need to account for the worst case (especially on home routers). What do you think?

Best Regards
	Sebastian

> 
> cake's bandwidth parameter can easily set a desirable max byte limit
> at (say) 2 or 4x the BDP, and key off of that and not bother to track
> a per packet limit.
> 
> It would be nice for cake (without shaping enabled) to be about to
> automatically sense the actual interface rate and size this outer
> limit appropriately, but I don't think mechanisms exist to do that.
> 
> 
> On Wed, Mar 18, 2015 at 2:20 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> 
>> On Wed, Mar 18, 2015 at 8:20 AM, Jonathan Morton <chromatix99@gmail.com>
>> wrote:
>>> 
>>> 
>>>> On 18 Mar, 2015, at 17:10, Kathleen Nichols <nichols@pollere.com> wrote:
>>>> 
>>>> How are you relating target delay to bandwidth?
>>> 
>>> Essentially, I use 5ms as a minimum, and increase it if necessary to
>>> accommodate a couple of MTU-sized packets at the shaping rate.  This keeps
>>> things nicely under control at low bandwidths, and I find that cake remains
>>> useful and usable even at 64Kbps (without making even the usual adjustments
>>> to host or link configuration for such low speeds).
>> 
>> 
>> In the cake2 (or maybe it was the unpublished cake3) version, I had a
>> lighter weight version of the codel algorithm, that did not have a target
>> parameter at all. Instead it just took the interval parameter and shifted it
>> right 4 (yielding a target of 6.xms from an interval of 100ms)
>> 
>> This saves on a memory access (and storage per queue!) , and I felt that any
>> differences in behavior would be unnoticeable. And they were. This is also
>> above the bound for cable-modem media access that greg white (rightly or
>> wrongly) believed existed. So I have no problem in eliminating "target"
>> entirely.
>> 
>> Cake (without bandwidth shaping engaged) uses more cpu than fq_codel did and
>> this was one of many optimizations I'd attempted (or successfully added).
>> Cake with shaping is a bit less cpu than sqm-scripts htb + fq_codel +
>> filters.
>> 
>> It also looked like cake could be poured into gates, with a bit more
>> research, and testing.
>> 
>>> 
>>> I can do this in cake because the shaping rate is known, whereas the pure
>>> codel and fq_codel qdiscs do not have reliable link-speed information.
>> 
>> 
>> As for this bit, we seemed to need to account for a MTU's worth of data at
>> the lower speeds, and I did not explore what fiddling with the interval and
>> auto-calc-ing the target did at these speeds, as yet.
>> 
>>> 
>>> - Jonathan Morton
>>> 
>>> _______________________________________________
>>> Codel mailing list
>>> Codel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/codel
>> 
>> 
>> 
>> 
>> --
>> Dave Täht
>> Let's make wifi fast, less jittery and reliable again!
>> 
>> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> 
> 
> 
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> 
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel


  parent reply	other threads:[~2015-03-22  9:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 20:08 Jonathan Morton
2015-03-18  7:22 ` Sebastian Moeller
2015-03-18  8:41   ` Jonathan Morton
2015-03-18 10:39     ` Sebastian Moeller
2015-03-18 15:10 ` Kathleen Nichols
2015-03-18 15:20   ` Jonathan Morton
2015-03-18 21:20     ` Dave Taht
2015-03-21 16:09       ` Dave Taht
2015-03-21 23:55         ` Jonathan Morton
2015-03-22  9:39         ` Sebastian Moeller [this message]
2015-03-22 10:43           ` Jonathan Morton
2015-03-22 12:51             ` Sebastian Moeller
2015-03-22 15:29               ` Jonathan Morton
2015-03-30 17:28               ` Jonathan Morton
2015-03-30 18:23                 ` Sebastian Moeller
2015-03-31  3:22                   ` Jonathan Morton
2015-03-31  7:12                     ` Sebastian Moeller
2015-03-31 12:47                       ` Jonathan Morton
2015-03-30 19:28                 ` Dave Taht
2015-04-02  4:48                   ` Jonathan Morton
2015-04-02  5:17                     ` Dave Taht
2015-04-02  5:19                       ` 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/codel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=B6540AAC-023D-433B-92B6-B435AA165874@gmx.de \
    --to=moeller0@gmx.de \
    --cc=chromatix99@gmail.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /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