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.
--
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
