On Thu, 2 Oct 2014, Alpha Sparc wrote:
How good is the throughput on CeroWrt compared to OpenWrt ?
The focus of CeroWrt is on reducing latency, not increasing throughput. If you
run into really badd bufferbloat problems without these scrips, then these
scripts can result more more 'goodput' (useable data as opposed to 'throughput'
bits on the wire) getting through, but in the usual case there will be a
(slight) reduction in the peak throughput.
This is especially so on the inbound side of things because the router is having
to work indirectly to throttle the senders so that they don't overload the
router at the other end of the connection.
I beleive that on the WNDR3800, it's able to work up to about 50Mb with the
existing configurations. A faster CPU would do better, a slower one worse. The
re-write that Dave is talking about is hoting to improve this. From the pastebin
link Dave listed below, they have it up to ~80Mb now
David Lang
On Oct 2, 2014 9:55 AM, "Dave Taht" <dave.t...@bufferbloat.net> wrote:
On Wed, Oct 01, 2014 at 12:10:46PM -0400, Weedy wrote:
On 30/03/14 06:29 PM, Dave Taht wrote:
On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote:
On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht <dave.t...@bufferbloat.net
wrote:
From: Dave Taht <dave.t...@bufferbloat.net>
This adds support for the bufferbloat project's "Smart Queue
Management"
(SQM) system, which improves over openwrt's qos-scripts in the
following
ways
+ Uses HTB with two models for managing traffic
a simplest one that merely uses fq_codel, and a three tier one
that does
some basic and tunable packet prioritization.
+ Works with ipv6 and ipv4 correctly (unlike qos-scripts)
+ extensive support for fixing ADSL and PPOe framing problems
+ Partial support for key diffserv markings
+ highly tuned fq_codel implementation especially for low bandwidths
+ Tested heavily on cable modems and on dsl devices
It is a disimprovement in that:
- There are no built-in tricks for doing l7 classification,
or other forms of packet inspection.
- We haven't explored hfsc all that much, prefering to rely
on the predictable behavior of htb + fq_codel for everything
- And there is support for a few qdiscs that are not in the linux
kernel mainline that remain experimental.
---
net/sqm-scripts/Makefile | 48 +++
net/sqm-scripts/files/etc/config/sqm | 11 +
net/sqm-scripts/files/etc/init.d/sqm | 23 ++
net/sqm-scripts/files/usr/lib/sqm/functions.sh | 335
++++++++++++++++++++
net/sqm-scripts/files/usr/lib/sqm/run.sh | 67 ++++
net/sqm-scripts/files/usr/lib/sqm/simple.qos | 187
+++++++++++
net/sqm-scripts/files/usr/lib/sqm/simple.qos.help | 1 +
net/sqm-scripts/files/usr/lib/sqm/simplest.qos | 84 +++++
.../files/usr/lib/sqm/simplest.qos.help | 1 +
net/sqm-scripts/files/usr/lib/sqm/stop.sh | 22 ++
10 files changed, 779 insertions(+)
create mode 100644 net/sqm-scripts/Makefile
create mode 100644 net/sqm-scripts/files/etc/config/sqm
create mode 100755 net/sqm-scripts/files/etc/init.d/sqm
create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh
create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh
create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos
create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help
create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos
create mode 100644
net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help
create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh
diff --git a/net/sqm-scripts/files/etc/config/sqm
b/net/sqm-scripts/files/etc/config/sqm
new file mode 100644
index 0000000..547d321
--- /dev/null
+++ b/net/sqm-scripts/files/etc/config/sqm
@@ -0,0 +1,11 @@
+
+config queue 'ge00'
+ option enabled '0'
+ option interface 'ge00'
+ option download '20000'
+ option upload '4000'
+ option qdisc 'fq_codel'
+ option script 'simple.qos'
+ option qdisc_advanced '0'
+ option linklayer 'none'
+
How hard is this to config from the command line/vim?
There are a few more options than this (for DSL compensation, ecn
and advanced configuration), the above would work if you changed
enabled to '1' and the device from ge00 to your wan device. (not
the "wan" firewall rule, presently. )
It does help to have a sane long term and realistic measurement of your
network using something like the rrul test rather than the oft-gamed
speedtest.
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310
You are right, we should fully document all the variables in this file.
Until recently they were kind of in flux.
I've never needed or really wanted luci on my box, I just use vim.
Going by
this patch, there is either nothing to config or no examples. I would
think
shipping a roughly equivalent config to what ships in qos-scripts
would be
a good start to get people testing.
/etc/init.d/sqm start,stop etc work as expected.
IE: highest priority: small ARP, DNS, and SSH packets
The SQM default is local DNS and ntp. fq_codel automagically optimizes
for other sparse flows like arp, ssh, mosh, tcp syn, synack, etc,
no need to do that via classification.
normal: HTTP, HTTPS
So you want to deprioritize vpn, smtp, rsync, dropbox, http on odd
ports,
caching servers, etc, all in favor of the web gods?
we just toss all that into the normal (best effort bin) and let
fq_codel
sort it out.
bulk: everything else.
We do respect the diffserv marking of CS1 (background) and toss it
into the background queue.
Side note: Will SQM do bandwidth slicing? Or at least handle "hostile"
environments better? I say "hostile" as in roommates or maybe teenage
kids.
Multiple people/devices thinking they are entitled to the entire WAN
bandwidth at all times.
fq_codel does fair (well, we call it "flow") queuing.
https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00
And manages the depth of flows via codel.
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02
In other words, it will be fair to all fat flows generated by everyone,
and slice flows down to the defined quantum and turn them back into
packets.
The "simplest.qos" model in SQM works remarkably well without trying to
classify anything at all. I encourage people to try merely that and
have
their preconceptions altered.
The three-tier model (simple.qos), is more like what people think they
want,
but the default is set to the bare minimum of what worked well in
testing.
Example: a lot of flows are marked CS1 that shouldn't be, and starving
that queue to like 5% rather than it's current 30% turned out badly.
In terms of identifying and "punishing" abusers, well, the only thing
that stresses this code out even the slightest is dozens of torrent
flows.
Give it a shot. :)
I feel like this died.
It didn't die.
*I* died.
I'd been on a death march for the last 8 months trying to
get the last bugs out of openwrt/cerowrt, and when the last big one
got fixed (bug 442 in the cerowrt database, multiple other trackers)
I put out a release of 3.10.50-1 pre BBrc1 and went to sleep.
When I woke up, about a week ago, everybody had nearly 2 months
uptime, good throughput, and a bunch of minor nits here and there.
Hooray!
The prospect of resyncing with BBrcX intimidates me, and I have
had a ton of other things that slid to take care of, so I've
been catching up on those. Sebastian has been taking
care of SQM nits...
https://github.com/dtaht/ceropackages-3.10/issues/8
And Jonathon morton has been pouring it all into
pure C - with an integral bandwidth shaper that we
hope will be faster and more efficient than htb.
See an early result:
http://pastebin.com/zz06WhJr
It takes much of the heavy lifting out of the existing
sqm scripts.
tc qdisc add dev eth1 root cake bandwidth 80mbit
So I don't know where to go. Certainly I'd like to
see the battle hardened sqm scripts (which are more
flexible than the C code above) get more widely used
and in BB.
openwrt users can do that today by adding the ceropackages repo to their
build system.
or just installing the sqm-scripts and luci-app-sqm.
or we can clean it up further for openwrt mainline.
But I haven't seen one core openwrt dev say, yes, we want this mainlined,
here's what you need to fix, so I'm inclined to go back to my cave, get
more sleep, and work on the successor.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
