Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
Dave Taht wrote: > On Sep 25, 2013 9:58 AM, "Eric Dumazet" > 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 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
On Sep 25, 2013 9:58 AM, "Eric Dumazet" 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! > > ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
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. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
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 1 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 a...@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 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
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 1 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. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12
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 RobertsThey showed the On 21 Sep 2013, at 01:18, Dave Taht wrote:The best writeup of Eric Dumazet's (and team's) latest assault onbloat was in lwn last month. The article just came out from behind thepaywall for general reading and is here:http://lwn.net/Articles/564978/(I haven't fiddled with these new features because I'm in the finalthroes of getting a decent beta of cerowrt out on 3.10.12 with someannoy-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/281023Anybody got relevant benchmarks?I am very happy to see the TSO/GSO sizing stuff as well. I hope thatthis will result in GSO doing sane things on 100Mbit and slowerdevices.-- Dave Täht___aqm mailing lista...@ietf.orghttps://www.ietf.org/mailman/listinfo/aqm___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
