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