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
next prev 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