is esfq discontinued ?

is esfq discontinued ?

[Akshat Kakkar]

Hi!
I tried to change the default queue to esfq by executing

echo "esfq" >  /proc/sys/net/core/default_qdisc

But I got error
bash: echo: write error: No such file or directory


However, if I execute
echo "sfq" >  /proc/sys/net/core/default_qdisc
then its accepts.

So is esfq discontinued?

Re: is esfq discontinued ?

[Andy Furniss]

Akshat Kakkar wrote:
> Hi! I tried to change the default queue to esfq by executing
>
> echo "esfq" >  /proc/sys/net/core/default_qdisc
>
> But I got error bash: echo: write error: No such file or directory

I can't even remember if it ever got in or not - but sfq hashing got the
same flexibility - from man tc-sfq

...

It is possible to use external classifiers with sfq, for example to hash
traffic based only on source/destination ip addresses:

# tc filter add ... flow hash keys src,dst perturb 30 divisor 1024

        Note that the given divisor should match the one used by sfq. If
you have changed the sfq default of 1024, use the same value for the
flow hash filter, too.

...

Re: is esfq discontinued ?

[Dave Taht]

I generally recommend retiring sfq in favor of fq_codel or cake.

On Thu, Sep 10, 2015 at 1:58 AM, Andy Furniss <adf.lists@gmail.com> wrote:
> Akshat Kakkar wrote:
>>
>> Hi! I tried to change the default queue to esfq by executing
>>
>> echo "esfq" >  /proc/sys/net/core/default_qdisc
>>
>> But I got error bash: echo: write error: No such file or directory
>
>
> I can't even remember if it ever got in or not - but sfq hashing got the
> same flexibility - from man tc-sfq
>
> ...
>
> It is possible to use external classifiers with sfq, for example to hash
> traffic based only on source/destination ip addresses:
>
> # tc filter add ... flow hash keys src,dst perturb 30 divisor 1024
>
>        Note that the given divisor should match the one used by sfq. If
> you have changed the sfq default of 1024, use the same value for the
> flow hash filter, too.
>
> ...
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo

Re: is esfq discontinued ?

[Andy Furniss]

Dave Taht wrote:
> I generally recommend retiring sfq in favor of fq_codel or cake.

Yea, though as flow hash keys doesn't get a mention in man tc-fq_codel I
didn't know if it would work.

Testing I see it does, though hashing on src with either qdisc kind of
takes away the nice aspects of their behavior WRT giving streams/new a
chance over bulk/existing.

 From the point of view of "being a user" having all my traffic sent to
one queue is not really what I would call QOS. I like my games to work
even if I am uploading :-)

Re: is esfq discontinued ?

[Dave Taht]

On Fri, Sep 11, 2015 at 2:08 AM, Andy Furniss <adf.lists@gmail.com> wrote:
> Dave Taht wrote:
>>
>> I generally recommend retiring sfq in favor of fq_codel or cake.
>
>
> Yea, though as flow hash keys doesn't get a mention in man tc-fq_codel I
> didn't know if it would work.

it works.

>
> Testing I see it does, though hashing on src with either qdisc kind of
> takes away the nice aspects of their behavior WRT giving streams/new a
> chance over bulk/existing.

yes.

>
> From the point of view of "being a user" having all my traffic sent to
> one queue is not really what I would call QOS. I like my games to work
> even if I am uploading :-)

We plan to add 2 depths of hashing options to "cake". Please join the
cake mailing list and make clear your requirements. It already
transparently supports the full 5 tuple, src or dst hashing.

http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical




-- 
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo

Re: is esfq discontinued ?

[Akshat Kakkar]

On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss <adf.lists@gmail.com> wrote:
> Dave Taht wrote:
>>
>> I generally recommend retiring sfq in favor of fq_codel or cake.
>
>
> Yea, though as flow hash keys doesn't get a mention in man tc-fq_codel I
> didn't know if it would work.
>
> Testing I see it does, though hashing on src with either qdisc kind of
> takes away the nice aspects of their behavior WRT giving streams/new a
> chance over bulk/existing.
>
> From the point of view of "being a user" having all my traffic sent to
> one queue is not really what I would call QOS. I like my games to work
> even if I am uploading :-)

Its all about being fair if bandwidth is shared across multiple users.

From the point of view of "being a user", I would not like my
neighbour to do an upload at 10Mbps and enjoy network games at
additonal 5 Mbps, and me (Oh! poor me) left with only 5 Mbps for my
job in which I have to _manage_ upload and games both.

So in this case it should be fairly distributed as 10 - 10 Mbps
between me and my neighbour. If I am not using, then my neighbour can
use my 10 Mbps or vice versa.

However, if the requirement is 10Mbps upload and 5 Mbps for Gaming,
then my neighbour should have a network plan where he is allotted
15Mbps to him and that is only for him and not at all community shared
and this should be handle by fq_codel per flow and not per IP.

So, if plan is per user it should be fq_codel per flow, if it is
shared plan then it should be fq_codel per src IP.

Re: is esfq discontinued ?

[Andy Furniss]

Dave Taht wrote:

> We plan to add 2 depths of hashing options to "cake". Please join
> the cake mailing list and make clear your requirements. It already
> transparently supports the full 5 tuple, src or dst hashing.
>
> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical

Cake does sound very interesting, though I personally don't have any
"requirements" as such any more. Which means any thoughts would just be
that and though I intend to "play" with it sometime it will just be fake
playing.

The 2 level hash does sound good if it is intended for the first to eg.
split bandwidth per user and the second to work within that for personal
prio/fairness.

One thought is that hashing on src ip in a home setup. would need to be
able to access the pre nat ip addresses.

Re: is esfq discontinued ?

[Akshat Kakkar]

> We plan to add 2 depths of hashing options to "cake". Please join the
> cake mailing list and make clear your requirements. It already
> transparently supports the full 5 tuple, src or dst hashing.
>
> http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical

+1 For 2 level hashing!

Re: is esfq discontinued ?

[Andy Furniss]

Akshat Kakkar wrote:
> On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss <adf.lists@gmail.com>
> wrote:
>> Dave Taht wrote:
>>>
>>> I generally recommend retiring sfq in favor of fq_codel or cake.
>>
>>
>> Yea, though as flow hash keys doesn't get a mention in man
>> tc-fq_codel I didn't know if it would work.
>>
>> Testing I see it does, though hashing on src with either qdisc kind
>> of takes away the nice aspects of their behavior WRT giving
>> streams/new a chance over bulk/existing.
>>
>> From the point of view of "being a user" having all my traffic sent
>> to one queue is not really what I would call QOS. I like my games
>> to work even if I am uploading :-)
>
> Its all about being fair if bandwidth is shared across multiple
> users.
>
>> From the point of view of "being a user", I would not like my
> neighbour to do an upload at 10Mbps and enjoy network games at
> additonal 5 Mbps, and me (Oh! poor me) left with only 5 Mbps for my
> job in which I have to _manage_ upload and games both.

OK but in the case of 2 sharing 20mbit then htb per ip + fq_codel for
each would solve that (assuming you wanted a simple just ip
classification scheme). I know many cases will not be so simple - many
users + lower bandwidth and your game traffic ends up waiting too long
for its turn. HFSC in theory may do that better - but you have to start
classifying traffic types and work out how to use HFSC!.

> So in this case it should be fairly distributed as 10 - 10 Mbps
> between me and my neighbour. If I am not using, then my neighbour
> can use my 10 Mbps or vice versa.
>
> However, if the requirement is 10Mbps upload and 5 Mbps for Gaming,
> then my neighbour should have a network plan where he is allotted
> 15Mbps to him and that is only for him and not at all community
> shared and this should be handle by fq_codel per flow and not per
> IP.
>
> So, if plan is per user it should be fq_codel per flow, if it is
> shared plan then it should be fq_codel per src IP.

I like the idea of being able to do both - but it's not as easy to
do/may not scale so well.

Re: is esfq discontinued ?

[Akshat Kakkar]

On Fri, Sep 11, 2015 at 6:25 PM, Andy Furniss <adf.lists@gmail.com> wrote:
> Akshat Kakkar wrote:
>>
>> On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss <adf.lists@gmail.com>
>> wrote:
>>>
>>> Dave Taht wrote:
>>>>
>>>>
>>>> I generally recommend retiring sfq in favor of fq_codel or cake.
>>>
>>>
>>>
>>> Yea, though as flow hash keys doesn't get a mention in man
>>> tc-fq_codel I didn't know if it would work.
>>>
>>> Testing I see it does, though hashing on src with either qdisc kind
>>> of takes away the nice aspects of their behavior WRT giving
>>> streams/new a chance over bulk/existing.
>>>
>>> From the point of view of "being a user" having all my traffic sent
>>> to one queue is not really what I would call QOS. I like my games
>>> to work even if I am uploading :-)
>>
>>
>> Its all about being fair if bandwidth is shared across multiple
>> users.
>>
>>> From the point of view of "being a user", I would not like my
>>
>> neighbour to do an upload at 10Mbps and enjoy network games at
>> additonal 5 Mbps, and me (Oh! poor me) left with only 5 Mbps for my
>> job in which I have to _manage_ upload and games both.
>
>
> OK but in the case of 2 sharing 20mbit then htb per ip + fq_codel for
> each would solve that (assuming you wanted a simple just ip
> classification scheme). I know many cases will not be so simple - many
> users + lower bandwidth and your game traffic ends up waiting too long
> for its turn. HFSC in theory may do that better - but you have to start
> classifying traffic types and work out how to use HFSC!.
>
>> So in this case it should be fairly distributed as 10 - 10 Mbps
>> between me and my neighbour. If I am not using, then my neighbour
>> can use my 10 Mbps or vice versa.
>>
>> However, if the requirement is 10Mbps upload and 5 Mbps for Gaming,
>> then my neighbour should have a network plan where he is allotted
>> 15Mbps to him and that is only for him and not at all community
>> shared and this should be handle by fq_codel per flow and not per
>> IP.
>>
>> So, if plan is per user it should be fq_codel per flow, if it is
>> shared plan then it should be fq_codel per src IP.
>
>
> I like the idea of being able to do both - but it's not as easy to
> do/may not scale so well.

Yes, its not at all that simple.

Might be as Dave is advocating, CAKE might be the solution with 2 level hash.