[Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Sebastian Moeller
moeller0 at gmx.de
Thu Oct 2 10:05:28 EDT 2014
Hi Weedy,
On Oct 2, 2014, at 05:46 , Alpha Sparc <alphasparc at gmail.com> wrote:
> How good is the throughput on CeroWrt compared to OpenWrt ?
I assume you are talking about the pure routing performance with no firewall/NAT and traffic-shaping involved? I think they pretty much are equal (pretty much the same kernel and most of the cerowrt guts are from openwrt bb trunk). But I have not tested that (I have only one cerowrt/openwrt capable router and that pretty much is my main router).
If you are talking about comparing QOS-scripts with SQM-scripts, they also seem to top out at roughly 50-60 Mbps (down- and uplink combined), it seems hfsc (qos-scripts) and HTB (sam-scripts) are equally expensive on MIPS.
Now if you are setup to do tests yourself I would love to hear the results. I would be happy to help you getting SQM-scripts to work (so far all people interested disappeared before or just after sharing initial test results).
Best Regards
Sebastian
>
> On Oct 2, 2014 9:55 AM, "Dave Taht" <dave.taht at 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.taht at bufferbloat.net>wrote:
> > >>
> > >>> From: Dave Taht <dave.taht at 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 at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the Cerowrt-devel
mailing list