From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Fri, 11 Sep 2015 12:55:53 +0000 Subject: Re: is esfq discontinued ? Message-Id: <55F2CF59.4040006@gmail.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Akshat Kakkar wrote: > On Fri, Sep 11, 2015 at 2:38 PM, Andy Furniss > 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.