From: Dave Taht <dave.taht@gmail.com>
To: codel@lists.bufferbloat.net
Subject: [Codel] proof of concept on embedded
Date: Sat, 5 May 2012 13:47:11 -0700 [thread overview]
Message-ID: <CAA93jw4+F-1n1h93S9qanuWstZ5f0qdKaZ+MBgnp1iMQj2291Q@mail.gmail.com> (raw)
I patched in the latest codel patch into cerowrt, bumping up the
control_law cache to 1000.
It worked. First time.
I was able to run ~230Mbit/sec ethernet traffic through it, which is
comparable to both sfq and pfifo_fast on this hardware (for reference
this is the netgear 3800 680Mhz mips box with a 16 bit memory
interface).
Might have been able to get more had I increased BQL's setting (which
is set to 3028, presently). With BQL in auto mode, BQL finds operating
points between 64k and 131k at these speeds.
RTTs stayed low.
I knew, based on the experiments back in november, that having the
dependency on timestamping was feasible, but it was another thing to
actually see it all work.
With htb on with a modified simple_qos.sh script to use codel rather
than sfqred, with htb set to rate limit at 2Mbit, using netperf via
wireless, I only got .86Mbit/sec for one stream and 1.4Mbit for 4. But
I'm currently willing to write that off to the unrelated bug 379.
root@codel:~# tc -s qdisc show dev ge00
qdisc htb 1: root refcnt 2 r2q 10 default 12 direct_packets_stat 9
Sent 13446791 bytes 9738 pkt (dropped 0, overlimits 29695 requeues 0)
backlog 0b 2p requeues 0
qdisc codel 110: parent 1:11 [Unknown qdisc, optlen=32]
Sent 15667 bytes 129 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc codel 120: parent 1:12 [Unknown qdisc, optlen=32]
Sent 13428070 bytes 9586 pkt (dropped 2710, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc codel 130: parent 1:13 [Unknown qdisc, optlen=32]
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 852437 bytes 10227 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Regrettably, due to another bug I've been battling for a month I can't
run traffic at that speed through it for more than 2 minutes or so.
( see http://www.bufferbloat.net/issues/379 371 and 360 for details ).
And last I looked qfq was still messed up on this arch.
But I've run plenty of traffic through it at normal speeds, so it's usable.
A test build for those of you that have this router is up at:
http://huchra.bufferbloat.net/~cero1/3.3/dev/3.3.4-5/
(didn't get the new iproute2 stuff on it on this pass though)
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
next reply other threads:[~2012-05-05 20:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-05 20:47 Dave Taht [this message]
2012-05-05 20:55 ` 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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw4+F-1n1h93S9qanuWstZ5f0qdKaZ+MBgnp1iMQj2291Q@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=codel@lists.bufferbloat.net \
/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