From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Goodman Date: Mon, 07 Jul 2014 10:59:42 +0000 Subject: Re: HFSC not working as expected Message-Id: <53BA7D9E.5090601@yescomputersolutions.com> List-Id: References: <53AC30A8.2080403@yescomputersolutions.com> In-Reply-To: <53AC30A8.2080403@yescomputersolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Once again thank you for your extremely useful input. I feel I am finally onto the home straight! I am going to experiment with the details you provided below... My reasoning regarding the 100mbit class is that in the some cases I have systems which are classifying VPN traffic before it is transmitted. With HTB I avoid accidentally shaping the encrypted trafffic by not having a default queue configured. Since all traffic is accounted for with netfilter marks and that traffic passes through the queues this works correctly. When I came to hfsc I was shocked to find that hfsc DROPS all traffic which isnt accounted for in a queue, so what you see is my attempt at emulating the 'old' functionality. Can you think of a better way to accomplish this? I am really confused about how I should set my downstream STAB... BT limits downstream throughput at the atm level to 88.2% of sync speed. Therefore with a 19560kbit sync I would expect to see 17251kbit throughput (atm). This matches up with what I see in the real world. My download shaping is on the upload of the my router to the network though. I am confident I need stab, so that for small packets the minimum atm cell size is accounted for, however I am a bit lost over what to set overhead and speed at. Overhead 0 with overrall rate 17100kbit results in only peak 14.4mbit throughput observed. Overhead 0 with overrall rate 19000kbit sees around 16.2mbit flowing - which is about perfect. Except BT limit the overall throughput on downstream to 88.2% of sync, which means the 19000kbit figure doesnt make sense to me? :-S Alan On 07/07/14 10:54, Michal Soltys wrote: > On 2014-07-06 17:34, Alan Goodman wrote: > >> Is it possible to iron this out, or is my unusual extreme test just too >> much? >> > Certainly, I have 24/7 torrent with uplink limits done solely by hfsc, > so it's certainly possible - I can't really tell if my torrent is even > on or off (core dumped ;) ). I have few extra patches, though > they should make little/no difference (at those speeds especially). > > Suggestions about your uplink rules (disabled word wrapping to make it > more readable): > >> tc class add dev ppp0 parent 1:0 classid 1:1 hfsc sc rate 100mbit ul rate 100mbit >> tc class add dev ppp0 parent 1:1 classid 1:2 hfsc sc rate 900kbit ul rate 900kbit > Unless the above is a typo, this makes no sense for ppp0 interface. You > should be covering the speed for what your uplink sync is. If it say > synchronizes at 1112248 bit/s (with some variation, but e.g. never lower > than 1100000), set > > tc qdisc add dev ppp0 root handle 1:0 hfsc stab overhead 40 linklayer atm default 14 > tc class add dev ppp0 parent 1:0 classid 1:1 hfsc ls m2 1100000 ul m2 1100000 > > Now why ls ? sc is shorthand for ls+rt, and rt functions only on leaf > classes with qdiscs attached (and outside class hierarchy). ul limits > the speed at which ls can send packets. ls is also relative only and > makes child classes send at ratio proportional to their values, e.g. > > A 100mbit, B 200mbit on 10mbit interface would mean that hfsc would send > data from those classes in 1:2 ratio - not try to send 300 mbit total > there (that would happen /if/ it was 'rt' and A & B were leaves). > > Remaining part (just an example): > > tc class add dev ppp0 parent 1:1 classid 1:10 hfsc sc m2 100kbit #syn ack rst > tc class add dev ppp0 parent 1:1 classid 1:11 hfsc sc m1 500kbit d 20ms m2 300kbit # Time critical > tc class add dev ppp0 parent 1:1 classid 1:12 hfsc sc m2 200kbit #Interactive > tc class add dev ppp0 parent 1:1 classid 1:13 hfsc sc m2 100kbit #bulk > tc class add dev ppp0 parent 1:1 classid 1:14 hfsc sc m1 100kbit d 20ms m2 300kbit # torrent and not-classified junk > > 'rt' sums to 1mbit, implied 'ls' will cover remaining bandwidth > proportionally. > > Unless you have special needs (aka killing speed for e.g. some customer > under some hierarchy subtree), avoid using 'ul' on anything but uppermost > class. > > Note: you don't have to use sc - you can use rt and ls separately - as > long as they make sense w.r.t. each other. In many situations, you don't > really need that precise and large 'rt' values when 'ls' can nicely > cover the rest.