Re: HFSC not working as expected

[Andy Furniss <adf.lists@gmail.com>]

Alan Goodman wrote:

> I added 'stab overhead 40 linklayer atm' to my root qdisc line since
> I am confident my connection uses LLC multiplexing.  This transformed
> the hfsc based shaper to being the most accurate I have so far
> experienced. I am able to set tc upload limit by the sync speed, and
> tc downstream by the sync minus 12% which accounts for some rate
> limiting BT do on all lines (they limit downstream to 88.2% of sync
> rate).

If you have the choice of pppoa vs pppoe why not use a so you can use
overhead 10 and be more efficient for upload.

THe 88.2 thing is not atm rate, they do limit slightly below sync,
but that is a marketing (inexact) approximate ip rate.

If you were really matching their rate after allowing for overheads your
incoming shaping would do nothing at all.

>
> This works great in almost every test case except 'excessive p2p'. As
> a test I configured a 9mbit RATE and upper limit m2 10mbit on my bulk
>  class.  I then started downloading a CentOS torrent with very high
> maximum connection limit set.  I see 10mbit coming in on my ppp0
> interface however latency in my priority queue (sc umax 1412b dmax
> 20ms rate 460kbit) however my priority queue roundtrip is hitting
> 100+ms. Below is a clip from a ping session which shows what happens
> when I pause the torrent download.

Shaping from the wrong end of the bottleneck is not ideal, if you really
care about latency you need to set lower limit for bulk and short queue
length.

As you have found hitting hard with many connections is the worse case.

I never really go into hfsc so can't comment on that aspect, but I have
in the past done a lot of shaping on BT adsl. In the early days of
288/576 it was very hard (for downstream). As the speeds get higher the
easier it gets WRT latency - 20/60mbit vdsl2 is easy :-)