Re: [Bloat] Getting started with sqm-scripts - latency good, bandwidth decimated

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 20/01/2016, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
> On 19/01/2016, Brandon Applegate <brandon@burn.net> wrote:
>> Disclaimer: if this is the wrong list for such a question - let me know.
>> This is specifically about the sqm-scripts package...
>>
>> Hello,
>>
>> I’ve been reading all I can on the bufferbloat website and also trying to
>> understand the evolution of the various scripts (debloat, sqm, etc).
>>
>> I managed to get sqm-scripts on my firewall (Ubuntu linux on a PC - no
>> *wrt
>> etc).  Got it built with the ‘linux’ platform.  Since this is Ubuntu 12.04
>> -
>> I had to cheat a bit and pull down the iproute2 source from 14.04.  I’ve
>> tweaked the main sqm script to reflect this for the tc bindary - this is
>> working.  I also updated my kernel to a later version that supports
>> fq_codel.
>>
>> My topology is ‘on a stick’.  I have one gig interface to a managed
>> switch,
>> on which are eth0.666 (outside/wan) and eth0.10 (inside).
>>
>> I have 30/5 cable service, and have tried both those values as well as
>> 90%
>> in my /etc/sqm/*conf file.
>>
>> I’ve tried both eth0 (raw/parent interface) as well as eth0.666.
>>
>> No matter what I do - my bandwidth is 10% of what it should be.  I get
>> approx. 3/4mbit down + 2/3mbit up on dslreports speedtest.  Bufferbloat
>> looks great though - A+.
>>
>> Is there something inherent I’m doing wrong ?  Something to do with my ‘on
>> a
>> stick’ topology biting me ?  Kernel version (Ubuntu’s 3.13.0-74-generic
>> btw).
>>
>> Thanks in advance for any help or info (or pointer to a more appropriate
>> list).
>
> It doesn't sound like you're doing anything wrong :(.
>
> I would make sure to check the rates on `tc class show dev eth0.666`
> (and ifb4eth0.666).  Switching to `simplest.qos` could be easier to
> debug.  With your simple.qos, there'll be several tracffic classes...
> the `root` should be the specified `rate`, and it looks like all
> classes save 1:11 should have a `ceil` just under the specified rate.
>
> Not sure how to debug qos-scripts itself.  However the Gentoo wiki has
> a 50-line script, which was corrected by dtaht :).  Like simplest.qos
> this has a single class.
> https://wiki.gentoo.org/wiki/Traffic_shaping
>
> That would let you investigate the commands finely, as well as the
> resulting state shown by `tc qdisc` and `tc class`, and really narrow
> it down.
>
> `dslreports.com` will show bandwidth and latency-under-load in each
> direction independently, so you could work on a single direction.  I
> would look at ingress only (the IFB) since that's where your bandwidth
> decimation is so visible.  E.g. just comment out the egress section,
> to avoid distractions.
>
> I think you can run the htb without the fq_codel command at the end -
> that is, it will default to a massive fifo, which will replace the
> fq_codel in the output of `tc qdisc`, but to a first approximation it
> will affect bandwidth.
>
> Good luck
> Alan

PS

The `ifb` part might be a bit mysterious.  If sqm-scripts is renaming
them, you could just remove the IFB kernel module & reload it to clear
the entire IFB config:

modprobe -r ifb

(the script includes "modprobe ifb" to load it as required)