Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Richard A. Smith" <richard@laptop.org>
Cc: Alpha Sparc <alphasparc@gmail.com>,
	openwrt-devel <openwrt-devel@lists.openwrt.org>,
	cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Date: Mon, 6 Oct 2014 21:41:25 +0200	[thread overview]
Message-ID: <F0FFACA2-B624-4F52-A0F9-FA31E85D8038@gmx.de> (raw)
In-Reply-To: <5432BD26.1070907@laptop.org>

Hi Richard,


On Oct 6, 2014, at 18:02 , Richard A. Smith <richard@laptop.org> wrote:

> On 10/02/2014 10:05 AM, Sebastian Moeller wrote:
> 
>> 	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).
> 
> Do you still need testers?  I have a bit of an interest here.

	Oh, sure every little bit of testing is helpful (especially on openwrt, as I am not setup to test openwrt at all). I might be that SQM-scripts will explode spectacularly, but I hope that there is only a little “impedance-mismatch” ;)

> 
> I have spare routers that I can run OpenWRT or CeroWRt on and I'm setup to test with netperf, netperf-wrapper on my local network
> ( desktop -> router -> laptop )  it's Gbit so I can easily saturate the router.

	That sounds great. I think the first test should be to run SQM under cerowrt, so you get a feel of how things should look. I typically run netperf-wrapper rrul tests (for ipv4 and if available for ipv6) through cerowrt with different settings for SQM. A second step then is to instal SQM-scripts under openwrt and check whether the same settings produce the same results ;)

> 
> What I don't have is a lot of time but I can do a few runs in the evenings or on weekends.  

	I think all that is needed is testing a few relevant shaping bandwidth combinations (always Downlink/Uplink, 3000Kbps/512Kbps, 16000Kbps/1000Kbps, 50000Kbps/10000Kbps, 100000Kbps/40000Kbps, and 0/50000Kbps, with a setting of 0 disabling shaping in a particular direction, 0/50000Kbps with the ethernet interface set 100Mbps, and with SQM disabled: pick the test set most relevant to your planned deployment to save time) And finally it would be great to test whether the ATM link layer encapsulation also works…
	Basically that is the set of things to test, but the most important is just testing one of them to see hw SQM-scripts (and luci-app-sqm works under stock openwrt)


> I also am very out of touch with the latest and greatest QoS vs SQM development and configuration so you will have to feed me test recipes.

	Oh, happy to help out with this, thanks to Toke’s netperf-wrapper my tests typically look like (for say 3000Kbps/512Kbps):
date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l 300 -s 0.4 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t IPv4_test_D3000Kbps-U512Kbps

followed by:
date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv6 -l 300 -s 0.4 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t IPv6_test_D3000Kbps-U512Kbps

for links faster than ~5Mbps or so you can skip the -s 0.4 line and for links slower than 2Mbps you probably need rouse -s 0.8 or even -s 1.0, running for 5 minutes (-l 300) makes sure you can also judge the robustness/stability of the shaping...
And then simply load the resulting output files in netperf-wrapper’s GUI to simplify comparison between the different SQM settings (and since these tests work independent of the used shaper you could also run the relevant shaper settings for your own situation through QOS. So you can compare how these two stack up against each other…)
	It might be a good idea to capture the output of:
logread
and:
tc -d qdisc
and
tc class show dev ge00 (for cerowrt, “tc class show dev wan” for openwrt, I believe)
before each test run on the router (this allows to confirm whether the selected shaper settings actually were applied properly)

I also, very unscientifically, ssh into the router while the tests are running and start “top -d 1” and visually monitor the %idle and %sirq (softinterrupts), the first goes to 0% and the second to >90% once you reached the your router’s shaping limit.

So just let me know what you are willing/ready to test and we will take it from there okay? (I would already be a happy camper if you could just install the current SQM-scripts on openwrt and just send me the output of “logread” after installing and activating SQM, as well as the output from “tc -d qdisc” before and after enabling SQM, and finally the output of running “/etc/init.d/sqm stop ; /etc/init.d/sqm start” on the router’s console; that hopefully works or at least gives some indication what might be off. If you could throw in a quick netperf-wrapper RRUL test through the router I will be most delighted ;))

Best Regards
	Sebastian


> 
> -- 
> Richard A. Smith  <richard@laptop.org>
> Former One Laptop per Child


  reply	other threads:[~2014-10-06 19:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1396119385-16871-1-git-send-email-dave.taht@bufferbloat.net>
     [not found] ` <1396119385-16871-2-git-send-email-dave.taht@bufferbloat.net>
     [not found]   ` <CAFE24U3s=z4jZkXMFU4xUyPyQ5fj95zOVxS7oBHGFuOp-FKXqw@mail.gmail.com>
     [not found]     ` <20140330222952.GA26806@lists.bufferbloat.net>
     [not found]       ` <542C2786.6090704@gmail.com>
2014-10-02  1:49         ` Dave Taht
2014-10-02  3:46           ` Alpha Sparc
2014-10-02 11:54             ` David Lang
2014-10-02 14:05             ` Sebastian Moeller
2014-10-06 16:02               ` Richard A. Smith
2014-10-06 19:41                 ` Sebastian Moeller [this message]
2014-10-09 16:42                   ` Richard Smith
2014-10-09 17:57                     ` Sebastian Moeller
2014-10-09 18:05                       ` Luis E. Garcia
2014-10-09 20:59                         ` Sebastian Moeller
2015-02-13  2:02                           ` Luis E. Garcia
2015-02-13  4:46                             ` Dave Taht
2015-02-13  5:13                               ` Luis E. Garcia
2014-10-09 18:13                       ` Dave Taht
2014-10-09 18:14                         ` Sebastian Moeller
     [not found]           ` <54359A46.8000107@iki.fi>
2014-10-09  3:01             ` Dave Taht
2014-10-09 17:09               ` Richard Smith
     [not found]             ` <CABXqzy77--kb59nedBnN+cLFGftN+gnBMJ9vi_xE8niP5YHEHw@mail.gmail.com>
2014-10-09  3:23               ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F0FFACA2-B624-4F52-A0F9-FA31E85D8038@gmx.de \
    --to=moeller0@gmx.de \
    --cc=alphasparc@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=richard@laptop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox