[Bloat] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Bloat] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Dave Taht]

The best writeup of Eric Dumazet's (and team's) latest assault on
bloat was in lwn last month. The article just came out from behind the
paywall for general reading and is here:

http://lwn.net/Articles/564978/

(I haven't fiddled with these new features because I'm in the final
throes of getting a decent beta of cerowrt out on 3.10.12 with some
annoy-the-nsa features in it. )

The only benchmark I've seen on the new scheduler so far was:

http://thread.gmane.org/gmane.linux.network/281023

Anybody got relevant benchmarks?

I am very happy to see the TSO/GSO sizing stuff as well. I hope that
this will result in GSO doing sane things on 100Mbit and slower
devices.

-- 
Dave Täht

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[James Roberts]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

No one responded to Luca's Sept 1 comment (on the bloat list) that the new code seems to do tail drop rather than longest queue drop. 

If this is so, bandwidth sharing will not be fair since FQ alone is not enough. This was shown in the previously cited Bell Labs paper : http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf. The following table is copied from the paper.


These results are a kind of benchmark showing that fairness needs both FQ and LQD. The paper also shows that a more easily implemented, approximate LQD works OK and avoids the need to sort flow queues in size order.

Jim Roberts



They showed the  
On 21 Sep 2013, at 01:18, Dave Taht wrote:

> The best writeup of Eric Dumazet's (and team's) latest assault on
> bloat was in lwn last month. The article just came out from behind the
> paywall for general reading and is here:
> 
> http://lwn.net/Articles/564978/
> 
> (I haven't fiddled with these new features because I'm in the final
> throes of getting a decent beta of cerowrt out on 3.10.12 with some
> annoy-the-nsa features in it. )
> 
> The only benchmark I've seen on the new scheduler so far was:
> 
> http://thread.gmane.org/gmane.linux.network/281023
> 
> Anybody got relevant benchmarks?
> 
> I am very happy to see the TSO/GSO sizing stuff as well. I hope that
> this will result in GSO doing sane things on 100Mbit and slower
> devices.
> 
> -- 
> Dave Täht
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


[-- Attachment #2.1: Type: text/html, Size: 2227 bytes --]

[-- Attachment #2.2: Screen shot 2013-09-24 at 14.06.09.png --]
[-- Type: image/png, Size: 24054 bytes --]

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Eric Dumazet]

On Tue, 2013-09-24 at 14:25 +0200, James Roberts wrote:
> No one responded to Luca's Sept 1 comment (on the bloat list) that the
> new code seems to do tail drop rather than longest queue drop. 
> 
> 
> If this is so, bandwidth sharing will not be fair since FQ alone is
> not enough. This was shown in the previously cited Bell Labs
> paper : http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf. The
> following table is copied from the paper.

This paper assumes TCP stack can push cwin packets in the queue.
We no longer have this behavior with linux.

If you have drops on FQ, then you have a serious problem with your
settings.

FQ is meant to be used on hosts, not on routers.

For routers, fq_codel is fine.

TCP Small Queues limits the number of packets in Qdisc for any tcp flow
(2 packets). Default FQ setting allows 10000 packets.

You can add tail drop on FQ if you really want, but I never had a single
drop in my FQ settings, on 20Gbps links and thousands of flows.

Therefore I did not add complexity to solve a non problem.

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Luca MUSCARIELLO]

Le 25/09/2013 17:15, Eric Dumazet a écrit :
> On Tue, 2013-09-24 at 14:25 +0200, James Roberts wrote:
>> No one responded to Luca's Sept 1 comment (on the bloat list) that the
>> new code seems to do tail drop rather than longest queue drop.
>>
>>
>> If this is so, bandwidth sharing will not be fair since FQ alone is
>> not enough. This was shown in the previously cited Bell Labs
>> paper : http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf. The
>> following table is copied from the paper.
> This paper assumes TCP stack can push cwin packets in the queue.
> We no longer have this behavior with linux.
>
> If you have drops on FQ, then you have a serious problem with your
> settings.
>
> FQ is meant to be used on hosts, not on routers.
>
> For routers, fq_codel is fine.
>
> TCP Small Queues limits the number of packets in Qdisc for any tcp flow
> (2 packets). Default FQ setting allows 10000 packets.
>
> You can add tail drop on FQ if you really want, but I never had a single
> drop in my FQ settings, on 20Gbps links and thousands of flows.
>
> Therefore I did not add complexity to solve a non problem.

Then, I feel like FQ is a bad name to call this "newFQ".
It's an implementation of a fair TCP pacer. Which is very useful, but FQ 
is kind of misleading, IMHO.

Luca



>
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
France Telecom R&D - Orange Labs
MUSCARIELLO Luca - OLN/NMP/TRM
38 - 40, rue du General Leclerc
92794 Issy Les Moulineaux Cedex 9 - France
Tel : +33 (0)1 45 29 60 37
http://perso.rd.francetelecom.fr/muscariello

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Eric Dumazet]

On Wed, 2013-09-25 at 17:38 +0200, Luca MUSCARIELLO wrote:

> Then, I feel like FQ is a bad name to call this "newFQ".
> It's an implementation of a fair TCP pacer. Which is very useful, but FQ 
> is kind of misleading, IMHO.

No problem, feel free to send a patch. I am very bad at choosing names.

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Sep 25, 2013 9:58 AM, "Eric Dumazet" <eric.dumazet@gmail.com> wrote:
>
> On Wed, 2013-09-25 at 17:38 +0200, Luca MUSCARIELLO wrote:
>
> > Then, I feel like FQ is a bad name to call this "newFQ".
> > It's an implementation of a fair TCP pacer. Which is very useful, but FQ
> > is kind of misleading, IMHO.
>
> No problem, feel free to send a patch. I am very bad at choosing names.

Fair TCP pacer = ftp # taken
Paced fair queue = pfq # lit collision
Enhanced paced queue = epq # pronounced epic!
>
>

[-- Attachment #2: Type: text/html, Size: 711 bytes --]

Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12

[Alex Elsayed]

Dave Taht wrote:

> On Sep 25, 2013 9:58 AM, "Eric Dumazet"
> <eric.dumazet@gmail.com> wrote:
>>
>> On Wed, 2013-09-25 at 17:38 +0200, Luca MUSCARIELLO wrote:
>>
>> > Then, I feel like FQ is a bad name to call this "newFQ".
>> > It's an implementation of a fair TCP pacer. Which is very useful, but
>> > FQ is kind of misleading, IMHO.
>>
>> No problem, feel free to send a patch. I am very bad at choosing names.
> 
> Fair TCP pacer = ftp # taken
> Paced fair queue = pfq # lit collision
> Enhanced paced queue = epq # pronounced epic!

There's also the option of 'Fair Queue Pacing', but I don't think we'd like 
how 'fqp' would be pronounced :P