[Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
David Lang
david at lang.hm
Thu Oct 2 07:54:55 EDT 2014
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.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
>>
>
-------------- next part --------------
_______________________________________________
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