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

[moeller0]

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?

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

Best Regards
	Sebastian


> 
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
> "SH1-0151.  This is the serial number, of our orbital gun."
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat