On 20/01/16 11:43, moeller0 wrote:
On Jan 20, 2016, at 11:12 , Alan Jenkins <[email protected]>
wrote:
On 19/01/2016, 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.
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.
It should be sufficient to set the egress rate to 0 then, as for sqm
zero denotes no shaping and not a rate of zero kbps (good luck using TCP on a
purely unidirectional link...)
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.
Simply put
QDISC=pfifo_fast
into the .conf file for eth0.666 to test this.
Best Regards
Sebastian
No offense to your work on sqm-scripts.
1) It's just in case the problem is *outside* of sqm-scripts, it could
be useful to try the minimum commands necessary to demonstrate the
problem. Maybe it's unfair but I assumed running on a PC is also a less
tested case, as well as the "firewall on a stick" part.
Equally, since AFAICT Brandon hasn't had a working AQM setup on this box
before. It could be useful if the Gentoo script works, to prove that
AQM + fq_codel can work correctly on Brandon's box.
If the Gentoo script _wasn't_ working, that's when I'd suggest tearing
it down e.g. to eliminate fq_codel as an issue. Rather than specify
fifo explicitly, just don't run the fq_codel command (assuming that
actually does something sensible, which can be checked using `tc qdisc`).
2) More specifically, you didn't mention trying "simplest.qos". This
would i) simplify the setup we're trying to debug, and ii) it might show
if there's a bug with the more complex bandwidth calculations /
assignments in "simple.qos".
And again - I suggest starting by checking `tc class show dev eth0.666`,
because it's not a 100% obvious command, and we don't want to miss if
there are bad rates there :).
Alan
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
