[Codel] what am i doing wrong? why isn't codel working?

Tue Jun 24 13:29:15 EDT 2014

On Tue, 2014-06-24 at 09:26 -0700, Dave Taht wrote: 
> Well, if your provided rate

I assume this is the rate from my DSL modem to the ISP, which is
~672Kb/s (although it's supposed to be 800kb/s

> is different from line rate on the up or
> down,

Which I assume is the rate between the OpenWRT router and the DSL modem?
If so, that's Gige, or at least that's what ethtool reports.  Given the
age of the DSL modem though, I am surprised it really is Gige.  I'd
think 100Mb/s at best.  Still, much faster than my provide rate.

> you need to apply a rate shaper to the interface first, not just
> fq_codel alone. You have to make your device be the bottleneck in
> order to have control of the queue.

So is that to say that I'm probably queuing in the bloated buffers of
the DSL modem and so need to feed the DSL modem at the rate it's feeding
upstream so as not to buffer there?

> openwrt has the qos-scripts and luci-app-qos packages

OK.  So having applied shaping to the upstream (and removing the default
classifications that luci-app-qos applies so everything is treated
equally), things look much better.  While saturating the uplink I got
the following ping response times:

88 packets transmitted, 88 received, 0% packet loss, time 87116ms
rtt min/avg/max/mdev = 11.924/25.266/96.005/10.823 ms

Those scripts appear to be using hfsc.  Is that better/worse than the
htb you suggested?

> A simple example of how htb is used in the above
> 
> http://wiki.gentoo.org/wiki/Traffic_shaping

Interestingly on my other WAN connection, I don't see much bufferbloat.
Given the following tc configuration:

qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 0: dev eth0.2 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc mq 0: dev wlan1 root 
qdisc mq 0: dev wlan0 root 
qdisc hfsc 1: dev pppoe-wan1 root refcnt 2 default 30 
qdisc fq_codel 100: dev pppoe-wan1 parent 1:10 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 200: dev pppoe-wan1 parent 1:20 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 300: dev pppoe-wan1 parent 1:30 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 400: dev pppoe-wan1 parent 1:40 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc ingress ffff: dev pppoe-wan1 parent ffff:fff1 ---------------- 
qdisc fq_codel 0: dev tun0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc hfsc 1: dev ifb0 root refcnt 2 default 30 
qdisc fq_codel 100: dev ifb0 parent 1:10 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 200: dev ifb0 parent 1:20 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 300: dev ifb0 parent 1:30 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
qdisc fq_codel 400: dev ifb0 parent 1:40 limit 800p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 

where the WAN interface is eth0.2 and has a provided rate of 55Mb/s down
and 10Mb/s up, a ping while saturating the uplink:

90 packets transmitted, 90 received, 0% packet loss, time 89118ms
rtt min/avg/max/mdev = 6.308/23.977/65.538/13.880 ms

Enabling the shaping on eth0.2 and repeating the test the ping times
are:

100 packets transmitted, 100 received, 0% packet loss, time 99117ms
rtt min/avg/max/mdev = 4.915/10.744/27.284/2.215 ms

So certainly more stable, but the non-shaped ping times were not
horrible.  Certainly not like on the choked down pppoe-wan1 interface.

In any case, it all looks good now.  Makes sense about preventing
queuing in the "on-site" equipment (DSL or cable modems) between my
router and the provider though.  I guess if that equipment's buffers
were not bloated I wouldn't need to do the shaping, is that right?

Maybe the buffers in the cable modem are so bloated and that's why it
doesn't suffer so badly?

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20140624/780b70e0/attachment.sig>