Re: HFSC not working as expected

[Alan Goodman <notifications@yescomputersolutions.com>]

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.