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

[Sebastian Moeller]

Hi Brandon,

First, thanks a lot.

On January 20, 2016 4:30:25 PM GMT+01:00, Brandon Applegate <brandon at burn.net> wrote:
>I’ll try to tackle what I can for now below inline.
>
>> On Jan 20, 2016, at 6:30 AM, moeller0 <moeller0 at gmx.de> wrote:
>> 
>> Hi Brandon,
>> 
>> 
>>> On Jan 20, 2016, at 00:33 , Brandon Applegate <brandon at 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.
>> 
>> 	Great, could I convince you to post a quick description of the
>required steps somewhere linkeable on the net (in case we actually get
>it to work correctly first ;) )
>> 
>>> 
>>> 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).
>> 
>> 	Okay, that is a configuration that has not received much testing in
>the past…
>> 
>>> 
>>> 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.
>> 
>> 	Eth0 is not going to work in that situation as you will send and
>receive both incoming and outgoing traffic on that interface, so we
>really need to configure it correctly on the VLAN interfaces. I would
>like to propose to start with egress/uplink first and handle ingress
>afterwards. If you select eth0.666 (the superstitious among us would
>probably try a different VLAN number ;) ) and only configure the upload
>bandwidth but set download to 0, effectively sqm will only try to shape
>the egress traffic. I would propose to try this first, if that works
>let’s tackle download/ingress okay
>
>I set DOWNLINK to 0 and here are the results (again - using
>speedtest.dslreports.com)
>
>Download: 36 mbit (bufferbloat through the roof)
>Upload: Slowly climbed to ~ 4.5mbit (bufferbloat good/very low)

Okay so it seems the uplink shaping is working as intended. Good so it seems you are ready to tackle ingress/download next ;)

>
>>> 
>>> No matter what I do - my bandwidth is 10% of what it should be.
>> 
>> 	Here a comprehensive list what you actually did might help to form
>educated hypothesis what is going on...
>> 
>>> I get approx. 3/4mbit down + 2/3mbit up on dslreports speedtest. 
>Bufferbloat looks great though - A+.
>> 
>> 	Mmmh, while I would love to declare success (bufferbloat quashed,
>let’s move on) I have a hunch you are not too impressed with that
>solution ;)
>> 
>>> 
>>> Is there something inherent I’m doing wrong ?
>> 
>> 	No, by all means you are doing the right thing, namely helping us
>making sqm robust under more different conditions, thanks.
>> 
>> 
>>> Something to do with my ‘on a stick’ topology biting me ?
>> 
>> 	Could be, but nobody knows.
>> 
>>> 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).
>> 
>> 	We recently taught sqm a whole new level of verbosity, please have a
>look at Readme.md on https://github.com/tohojo/sqm-scripts , I believe
>under non openwrt systems you might need to set:
>> [ -z "$SQM_VERBOSITY" ] && SQM_VERBOSITY=$VERBOSITY_DEBUG
>> instead of the default:
>> [ -z "$SQM_VERBOSITY" ] && SQM_VERBOSITY=$VERBOSITY_INFO
>> and then issue:
>> /usr/bin/sqm/sqm-bin stop
>> /usr/bin/sqm/sqm-bin start
>> manually to get more verbose output, You could also try setting
>SQM_DEBUG unconditionally to 1 in defaults.sh (in addition to raising
>the default log level to SQM_DEBUG) to get debug logs under:
>> /var/run/sqm/eth0.666.debug.log
>> or similar. That ideally will contain all debug output as well as all
>calls to the tc and ip and iptables binaries and their output, which
>should be plenty information to figure out the root cause of your
>issues.
>
>I can’t get it to log anything for the life of me.  I’ve tried:
>
>SQM_DEBUG=1 SQM_VERBOSITY=8 /etc/init.d/sqm stop ; SQM_DEBUG=1
>SQM_VERBOSITY=8 /etc/init.d/sqm start

I am unsure whether this will work outside of openwrt, as we needed some extra code in run.sh to pass these on from the command line.
>
>As well as temporarily mucking around in the defaults.sh script.  It
>never writes anything to the /var/run (but the state gets written, so I
>don’t think it’s perms).

That is sad. Maybe we try to solve your real problem first and then maybe if you are still patient enough we could try to improve sqm scripts?
Best Regards
        Sebastian

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.