Hi Brandon, One more (very) simple test - what are your speeds *without* any SQM/shaping? I didn't see it mentioned in your report, and let's be sure that you're shaping the traffic to the actual achievable link speeds...
I recently helped a friend whose "15 mbps/1mbps" DSL just wouldn't get above ~725kbps up without inducing latency/bloat. It turns out that the uplink could only achieve 3/4 of its "rated" speed. Best, Rich > On Jan 20, 2016, at 6:30 AM, moeller0 <[email protected]> wrote: > > Hi Brandon, > > >> On Jan 20, 2016, at 00:33 , Brandon Applegate <[email protected]> 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
