Hi Weedy,
On Oct 2, 2014, at 05:46 , Alpha Sparc <alphasp...@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.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
