From: Jonathan Morton <chromatix99@gmail.com>
To: cake@lists.bufferbloat.net
Subject: Re: [Cake] cake exploration
Date: Mon, 13 Apr 2015 01:44:10 +0300 [thread overview]
Message-ID: <81A130E2-00C8-4141-BB10-823699DA7DD0@gmail.com> (raw)
In-Reply-To: <CAA93jw7t=YNrJB+Ja60P_dGSLgo8b4KudxQBM7aqHCyj67M6vA@mail.gmail.com>
Okay, lots of things to think about all at once. Cherry-picking:
> 5) Byte Mode-ish handling
>
> Dropping a single 64 byte packet does little good. You will find in
> the 50 flow tests that a ton of traffic is acks, not being dropped,
> and pie does better in this case than does fq, as it shoots
> wildly at everything, but usually misses the fat packets, where DRR
> will merrily store up an entire
> MTU worth of useless acks when only one is needed.
>
> So just trying to drop more little packets might be helpful in some cases.
>
> 6) Ack thinning. I gave what is conventionally called "stretch acks" a
> new name, as stretch acks
> have a deserved reputation as sucking. Well, they dont suck anymore in
> linux, and what I was
> mostly thinking was to drop no more than 2 in a row...
>
> One thing this would help with is in packing wifi aggregates - which
> have hard limits on the number of packets in a TXOP (42), and a byte
> limit on wireless n of 64k. Sending 41 acks from
> one flow, when you could send the last 2, seems like a big win on
> packing a TXOP.
>
> (this is something eric proposed, and given the drop rates we now see
> from wifi and the wild and wooly internet I am inclined to agree that
> it is worth fiddling with)
>
> (I am not huge on it, though)
Okay, dropping individual 64-byte packets does little good. But transmitting 64-byte packets costs very little. On the gripping hand, receiving and processing 64-byte packets is probably disproportionately expensive; probably much of our forwarding CPU overhead is per-packet, not per-byte. (This could be tested by reducing MTU and seeing how much the CPU saturation threshold moves.)
Here’s something important: ECE-Echo is carried on acks.
As far as wifi is concerned, if you’ve got 42 acks from one flow aggregating into one transmit opportunity, then I’d say that’s a very rare and degenerate case. Maybe it happens occasionally on real traffic, but it would be a transient condition - not occurring continuously. So it only matters if there’s competing traffic for the same station, and that’s something we can tackle a different way.
> 7) Macaddr hashing on the nexthop instead of the 5tuple. When used on
> an internal, switched network, it would be better to try and maximize
> the port usage rather than the 5 tuple in some cases.
We’ve sort-of almost got that already with “dsthost" mode.
> Personally I do not think that the 8 way set associative has is what
> wifi needs for cake, I tend to think we need to "pack" aggregates with
> as many different flows as possible, and randomize how we packet
> them... I think.... maybe….
Wifi needs per-flow fairness on a per-station basis, ie. not hashing the entire 5-tuple at once, but processing different parts of it separately.
That’s potentially a good thing in the more general case, actually; at the moment, with multiple hosts served by a single cake instance, one user can outcompete another by simply using more flows.
> 13) It might be possible to write a faster codel - and easier to read
> by using a case statement on the 2 core variables in it. The current
> code does not show the 3 way state machine as well as that could, and
> for all I know there is something intelligent we could do with the 4th
> state.
Yes. Easier to read code may even turn out to be faster (for a variety of reasons), and will certainly be easier for hardware folks to get their heads around.
- Jonathan Morton
prev parent reply other threads:[~2015-04-12 22:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-11 18:44 Dave Taht
2015-04-11 18:45 ` Dave Taht
2015-04-11 18:47 ` Dave Taht
2015-04-11 18:48 ` Dave Taht
2015-04-11 19:12 ` Dave Taht
2015-04-12 2:33 ` Dave Taht
2015-04-12 22:52 ` Jonathan Morton
2015-04-12 23:14 ` Jonathan Morton
2015-04-13 15:54 ` Dave Taht
2015-04-12 22:44 ` Jonathan Morton [this message]
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=81A130E2-00C8-4141-BB10-823699DA7DD0@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
/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