[Bloat] DSLReports Speed Test has latency measurement built-in

[Dave Taht]

On Thu, May 7, 2015 at 8:54 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Thu, 2015-05-07 at 16:09 -0700, Dave Taht wrote:
>
>> Recently I did some tests of 450+ flows (details on the cake mailing
>> list) against sch_fq which got hopelessly buried (10000 packets in
>> queue). cake and fq_pie did a lot better.
>
> Seriously, comparing sch_fq against fq_pie or fq_codel or cake is quite
> strange.

I have been beating back the folk that think fq is all you need for almost
as long as the pure aqm'rs. Sometimes it makes me do crazy stuff like
that test... or use pfifo_fast... just to have the data.

In the 450 flow test, I was actually trying to exercise cake's ultimate
deal-with-the-8way-set-associative collision code path, and ran the
other  qdiscs for giggles. I did not expect sch_fq to hit a backlog of
10k packets, frankly.

> sch_fq has no CoDel part, it doesn't drop packets, unless you hit some
> limit.

> First intent for fq was for hosts, to implement TCP pacing at low cost.

that was a test on a 1gige server running those qdiscs, not a router.

I am sure the pacing bit works well when the host does not saturate
its own card, but when it does, oh, my!

>
> Maybe you need an hybrid, and this is very possible to do that.

fq_pie did well, as did cake.

> I did recently one change in sch_fq. where non local flows can be hashed
> in a stochastic way. You could eventually add CoDel capability to such
> flows.
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=06eb395fa9856b5a87cf7d80baee2a0ed3cdb9d7

I am aware of that patch.

My own take on things was that TSQ needs to be more aware of the total
number of flows in this case.


>
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67