From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.klug.on.ca (server.klug.on.ca [205.189.48.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8400F21F22D for ; Tue, 24 Jun 2014 10:29:22 -0700 (PDT) Received: from linux.interlinx.bc.ca (69-165-217-196.dsl.teksavvy.com [69.165.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.klug.on.ca (Postfix) with ESMTP id 26C261BCCB; Tue, 24 Jun 2014 13:29:42 -0400 (EDT) Received: from [10.75.22.1] (pc.ilinx [10.75.22.1]) by linux.interlinx.bc.ca (Postfix) with ESMTP id 0DFBE8C3F; Tue, 24 Jun 2014 13:29:16 -0400 (EDT) Message-ID: <1403630955.3478.767.camel@pc.interlinx.bc.ca> From: "Brian J. Murrell" To: Dave Taht Date: Tue, 24 Jun 2014 13:29:15 -0400 In-Reply-To: References: <1403616175.3478.731.camel@pc.interlinx.bc.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GUkbIF7QQeO2ThBQht1/" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Cc: "codel@lists.bufferbloat.net" Subject: Re: [Codel] what am i doing wrong? why isn't codel working? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 17:29:22 -0000 --=-GUkbIF7QQeO2ThBQht1/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2014-06-24 at 09:26 -0700, Dave Taht wrote:=20 > 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 =3D 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 >=20 > 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=20 qdisc fq_codel 0: dev eth0.2 root refcnt 2 limit 1024p flows 1024 quantum 3= 00 target 5.0ms interval 100.0ms ecn=20 qdisc mq 0: dev wlan1 root=20 qdisc mq 0: dev wlan0 root=20 qdisc hfsc 1: dev pppoe-wan1 root refcnt 2 default 30=20 qdisc fq_codel 100: dev pppoe-wan1 parent 1:10 limit 800p flows 1024 quantu= m 300 target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 200: dev pppoe-wan1 parent 1:20 limit 800p flows 1024 quantu= m 300 target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 300: dev pppoe-wan1 parent 1:30 limit 800p flows 1024 quantu= m 300 target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 400: dev pppoe-wan1 parent 1:40 limit 800p flows 1024 quantu= m 300 target 5.0ms interval 100.0ms ecn=20 qdisc ingress ffff: dev pppoe-wan1 parent ffff:fff1 ----------------=20 qdisc fq_codel 0: dev tun0 root refcnt 2 limit 1024p flows 1024 quantum 300= target 5.0ms interval 100.0ms ecn=20 qdisc hfsc 1: dev ifb0 root refcnt 2 default 30=20 qdisc fq_codel 100: dev ifb0 parent 1:10 limit 800p flows 1024 quantum 300 = target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 200: dev ifb0 parent 1:20 limit 800p flows 1024 quantum 300 = target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 300: dev ifb0 parent 1:30 limit 800p flows 1024 quantum 300 = target 5.0ms interval 100.0ms ecn=20 qdisc fq_codel 400: dev ifb0 parent 1:40 limit 800p flows 1024 quantum 300 = target 5.0ms interval 100.0ms ecn=20 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 =3D 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 =3D 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. --=-GUkbIF7QQeO2ThBQht1/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJTqbVrAAoJENrB0DQWy8igMvwIAIAT4Wm9Fudw+BUShkmh3LBU 9XLQla2v6pf0hudI2+MpDs9foMG8N4x49UJay68+O9RtL0bVVk7ll3OGPl45MxkF N1E2Mx5mKhJMHmQAhqzmVhfwIlKvCNN667x4PoOi/mJJ6imBK5NMTjH6u4StbmiK SuxCEmdCZcEQnF2TIeNlnfg27v36XZqkNnFFTMnSyyrYlKxcISu1yrDspFCS4sCg cQmeO6lvfJT3VzEXG9XrofUHsVUeLBqjRP2ZihFfeKyMx465/IK8IVHQ1Sb7SYWV 8fQQle699bhdgryc5/qS0SQliimFbxvSlQ6ZQdKGf6Vqc7TVbk0PzgZF50rJLcY= =hk6t -----END PGP SIGNATURE----- --=-GUkbIF7QQeO2ThBQht1/--