Re: is esfq discontinued ?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 11, 2015 at 6:25 PM, Andy Furniss <adf.lists@xxxxxxxxx> wrote:
> Akshat Kakkar wrote:
>>
>> On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss <adf.lists@xxxxxxxxx>
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux