From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: Dave Taht <dave.taht@gmail.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
Felix Fietkau <nbd@openwrt.org>, Tim Shepard <shep@alum.mit.edu>
Subject: Re: [RFC/RFT] mac80211: implement fq_codel for software queuing
Date: Tue, 08 Mar 2016 11:19:59 +0100 [thread overview]
Message-ID: <87d1r5tgog.fsf@toke.dk> (raw)
In-Reply-To: <CA+BoTQk+3jhwK57_fDw0scNCGzu_Edqp9-Beeppz8xj9kSQcoQ@mail.gmail.com> (Michal Kazior's message of "Tue, 8 Mar 2016 08:12:21 +0100")
Michal Kazior <michal.kazior@tieto.com> writes:
>> With large values for flows_cnt, fq, dominates, for small values, aqm
>> does. We did quite a lot of testing at 16 and 32 queues in the early
>> days, with pretty good results, except when we didn't. Cake went whole
>> hog with an 8 way set associative hash leading to "near perfect" fq,
>> which, at the cost of more cpu overhead, could cut the number of
>> queues down by a lot, also. Eric did "perfect" fq with sch_fq...
>
> Out of curiosity - do you have any numbers to compare against
> fq_codel? Like hash collision probability vs number of active flows?
Basically, the analytical expression for hash collisions is fairly
straight forward (though I can't take credit for coming up with it
myself):
Given N bins with M items being hashed into them by a hypothetical
perfectly uniform hash, you get:
Expected number of bins with x items = N * (1/N)^x * (1 - 1/N) ^ (M - x) * C(M, x)
where C(M, x) is the combinatorial function = M! / (x! * (M-x)!).
By expanding this expression for x=1 and dividing by M, you get the
probability that one of your M items is in its own bin. Subtract this
from 1 and you get the collision probability.
I have a neat spreadsheet to compute this for arbitrary numbers; but for
a 1024-bin FQ-Codel this gives a collision probability of just under 1%
for 10 flows, and just over 9% for 100 flows. This is not too far off
from actual values in a real-world hashing function.
Now, to add to the confusion, you also have to take into account that an
active flow (from an end-to-end perspective) does not necessarily
translate into an active flow from the queue perspective. And that in
fact the number of active flows in a router can be significantly less
than the number of active end-to-end flows, and scales sub-linearly...
There has been at least one paper demonstrating this, but right now I
can't recall who wrote it.
-Toke
next prev parent reply other threads:[~2016-03-08 10:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 13:09 [RFC/RFT] mac80211: implement fq_codel for software queuing Michal Kazior
2016-02-26 16:48 ` Felix Fietkau
2016-02-26 16:48 ` Felix Fietkau
2016-02-26 18:54 ` Michal Kazior
2016-03-01 14:02 ` Johannes Berg
2016-03-02 7:38 ` Michal Kazior
2016-03-03 17:00 ` Dave Taht
2016-03-03 17:00 ` Dave Taht
2016-03-04 2:48 ` Tim Shepard
2016-03-04 6:32 ` Michal Kazior
2016-03-07 14:05 ` Avery Pennarun
2016-03-07 14:05 ` Avery Pennarun
2016-03-07 15:09 ` Felix Fietkau
2016-03-07 15:09 ` Felix Fietkau
2016-03-07 16:25 ` Avery Pennarun
2016-03-07 16:25 ` Avery Pennarun
2016-03-07 16:54 ` Dave Taht
2016-03-07 16:54 ` Dave Taht
2016-03-07 17:14 ` Avery Pennarun
2016-03-07 17:14 ` Avery Pennarun
2016-03-07 17:22 ` Grumbach, Emmanuel
2016-03-07 17:22 ` Grumbach, Emmanuel
2016-03-07 18:28 ` Dave Taht
2016-03-08 7:41 ` Michal Kazior
2016-03-08 7:41 ` Michal Kazior
2016-03-07 23:06 ` Dave Taht
2016-03-07 23:06 ` Dave Taht
2016-03-08 7:12 ` Michal Kazior
2016-03-08 10:19 ` Toke Høiland-Jørgensen [this message]
2016-03-08 13:14 ` Bob Copeland
2016-03-08 13:27 ` Michal Kazior
2016-03-10 18:57 ` Dave Taht
2016-03-10 18:57 ` Dave Taht
2016-03-11 8:32 ` Michal Kazior
2016-03-08 10:57 ` Michal Kazior
2016-03-08 10:57 ` Michal Kazior
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1r5tgog.fsf@toke.dk \
--to=toke@toke.dk \
--cc=dave.taht@gmail.com \
--cc=emmanuel.grumbach@intel.com \
--cc=eric.dumazet@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
--cc=nbd@openwrt.org \
--cc=netdev@vger.kernel.org \
--cc=shep@alum.mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.