[Cerowrt-devel] Status of SQM-Scripts integration into OpenWRT Barrier Breaker?
Frits Riep
riep at riepnet.com
Mon Aug 25 08:37:21 EDT 2014
>From earlier notes in the list, and from the CeroWRT Wiki, I believe the
intent is to back port SQM into OpenWRT.
As there are a wide variety of hardware platforms supported under OpenWRT,
if SQM scripts, and a Luci-App-SQM, then many installed base routers, and
readily available routers would greatly benefit.
I may be misunderstanding, but I thought this was a goal. Am I incorrect,
or have the plans changed?
Also, I do have some questions.
* I believe fq-codel is integrated into the latest available
versions of Linux. If so, other than setting upload and download limits, do
we already have buffer control handled with all newer OpenWRT releases?
* If so, do we still need to download and configure the packages,
QOS-Scripts, and Luci-App-Qos? If so, do these packages do anything besides
allow the configuration of Upload and Download limits?
* If we can, in fact, control bufferbloat with OpenWRT and the
latest Qos-scripts and Luci-App-QOS, then would the integration of SQM into
OpenWRT provide much benefit in controlling bloat? If so, are there still
plans to make that happen.
I am very happy with the configuration of my home router running CeroWRT on
a Netgear WNDR-3800 (running close to the latest build), on a Verizon FIOS
connection at 75 Mbs Down / and 75 Mbs Up, and on running pings with
Speedtest notice a definate difference in latency (very tight control) vs up
to 100 ms latency.
Thanks to all for the good work, and I hope that these are useful questions.
Frits
-----Original Message-----
From: cerowrt-devel-bounces at lists.bufferbloat.net
[mailto:cerowrt-devel-bounces at lists.bufferbloat.net] On Behalf Of
cerowrt-devel-request at lists.bufferbloat.net
Sent: Sunday, August 24, 2014 2:55 PM
To: cerowrt-devel at lists.bufferbloat.net
Subject: Cerowrt-devel Digest, Vol 33, Issue 23
Send Cerowrt-devel mailing list submissions to
<mailto:cerowrt-devel at lists.bufferbloat.net>
cerowrt-devel at lists.bufferbloat.net
To subscribe or unsubscribe via the World Wide Web, visit
<https://lists.bufferbloat.net/listinfo/cerowrt-devel>
https://lists.bufferbloat.net/listinfo/cerowrt-devel
or, via email, send a message with subject or body 'help' to
<mailto:cerowrt-devel-request at lists.bufferbloat.net>
cerowrt-devel-request at lists.bufferbloat.net
You can reach the person managing the list at
<mailto:cerowrt-devel-owner at lists.bufferbloat.net>
cerowrt-devel-owner at lists.bufferbloat.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Cerowrt-devel digest..."
Today's Topics:
1. SQM vs DSL (Sebastian Moeller)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Aug 2014 20:54:49 +0200
From: Sebastian Moeller < <mailto:moeller0 at gmx.de> moeller0 at gmx.de>
To: Dave T?ht < <mailto:dave.taht at gmail.com> dave.taht at gmail.com>,
cerowrt-devel
< <mailto:cerowrt-devel at lists.bufferbloat.net>
cerowrt-devel at lists.bufferbloat.net>
Subject: [Cerowrt-devel] SQM vs DSL
Message-ID: < <mailto:7E74D1C2-5686-40C4-813B-23BE96D736E5 at gmx.de>
7E74D1C2-5686-40C4-813B-23BE96D736E5 at gmx.de>
Content-Type: text/plain; charset="windows-1252"
Hi Dave, hi List,
to avoid real work I embarked on a (quick) test of my DSL line?s bloat
(again). Since I just realized that my ISP has increased my per-packet
overhead from 40 bytes to 44 bytes (probably by switching onto a platform
that uses VLAN tags between DSL-modem and DSLAM/BRAS, but I digress) my
recent netperf-wrapper tests all had been invalidated, since most likely the
link layer encapsulation was wrong. So I set out to figure out how close I
can shape my DSL line ad still keep decent behavior under load. I used
Toke?s great netperf-wrapper (the RRUL test to be precise) against
netperf-eu.bufferbloat.net and tested a number of different up- and
downstream shaping values (on an ATM based adsl2+ line with a line rate of
17613Kbps down and 2604 Kbps up, for all tests the proper link layer
encapsulation (ATM with overhead 44) has been used) from a macbook attached
via the 5GHz radio.
The first interesting result is that for my line shaping the
upstream to 2000Kbps (76%) actually shows no better ICMP-CDF than shaping to
2575Kbps (98.9%) or even 2604 (100%) independent of the shaping of the
downstream. Actually, the slower the uplink gets the larger the average
latency gets, just as the upstream target value increases to counter the
longer transfer times ("tc -d qdisc? on cerowrt will tell the actual
effective target values).
Downstream shaping results however are more interesting and
less clear.
Attached are three plots of a number of experiments with
different downstream-shaping values from 8000 Kbps (8000KU2604K in the
legend) up to the line-rate at 17613Kbps (17613KU2604K) to no shaping
(0KU0K, that is SQM configured with 0 for up- and downstream). It is quite
obvious that no shaping has the highest good-put but at a terrible latency
cost (and the DSL-modem is not terribly over-buffered with 85% of the ICMP
CDF still below 100ms, but several excursions into the >1000ms range). All
downstream shaping values at this overview scale show a massive improvement
of latency under load.
The second plot (*ping_box_scaled.png) shows once more that
no shaping is bad for latency under load (from left to right UDP BE, UDP BK,
ICMP, UDP EF, averages). Also quite obvious, shaping the downstream just to
line rate (gray box: 17613, 100%) still does not give too good a result with
lots of variability (but way better than no shaping). Decreasing the
downstream further improves the averages for all latency probes but
relatively mild compared to the no-shaping and 100% line-rate shaping
conditions. After the tests I converged on 15852 (90%) and 2575 (99%)
which on average shows a increase of latency under load of 15ms pretty close
to the theoretical expected value of 10ms (5ms codel target in each
direction), which given the access via WLAN is quite decent. (Also a wired
test afterwards showed an average increase go 11ms close enough to theory to
call it a day.)
I guess the 2 interesting points are:
1) With a non-congested DSLAM, DSL upstream shaping can be pushed
to the extreme of 100% of line rate without having to pay a severe price in
latency growth under load. (I remember that we had a discussion that
DSL-modems should learn fq_codel so we could regain the lost upstream
bandwidth; I guess with proper handling of the encapsulation there is no
bandwidth left on the table ;) Still it would be so much nicer if all modems
would do this by themselves).
2) On the downstream side of shaping, it really seems to be a
question of figuring out which trade-off between bandwidth and latency under
load one is willing to accept. (And finally note to self, perform future
tests with a wired connection until wifi is fast ;) )
P.S.: I hope the images are not too large and still
readable.
Best Regards
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/
63b73396/attachment.html>
https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/6
3b73396/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsl_shaping_140824_totals.png
Type: image/png
Size: 58371 bytes
Desc: not available
URL: <
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/
63b73396/attachment.png>
https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/6
3b73396/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsl_shaping_140824_ping_box_scaled.png
Type: image/png
Size: 88710 bytes
Desc: not available
URL: <
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/
63b73396/attachment-0001.png>
https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140824/6
3b73396/attachment-0001.png>
------------------------------
_______________________________________________
Cerowrt-devel mailing list
<mailto:Cerowrt-devel at lists.bufferbloat.net>
Cerowrt-devel at lists.bufferbloat.net
<https://lists.bufferbloat.net/listinfo/cerowrt-devel>
https://lists.bufferbloat.net/listinfo/cerowrt-devel
End of Cerowrt-devel Digest, Vol 33, Issue 23
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140825/6883c8c5/attachment-0002.html>
More information about the Cerowrt-devel
mailing list