From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2C8E921F199 for ; Tue, 27 Aug 2013 13:58:10 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 1so2905291qec.21 for ; Tue, 27 Aug 2013 13:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/gEr1iD/rLabvDYjkFodH054EAcleFCtcuMQmfyFs/8=; b=HFHsmo1jLVcgKP3YFZZcnq2p1RvUt4F9nr6ScZRU2gcNrHvgyXxA7d9Tcdr9DoQ4sS L/7RnA9191r/LiqMMHRlwGWfzRC19Pa6jNNyPI7TUoDh539OTOf8031dNzLWYINNsKUJ 9C31w6soeG8MejEMOOOJHZXTq7YyNi916Qo6PBn67t04mrAHCA0cwQ5ggT0Sq4KWIeag LtEkXp4qAEAaV9oqPnp7HwaEWn+ibduEtbMdLWvdFiAGNO4X1rJeWBDxyYopzQiCY5AC NM+2DhsZPwVVn5VUQ6XaDy2XWuqGt7+WHgBF9xh6hdn4yzWMOu0tI6nUD2Oim5hiWu4u sM7g== MIME-Version: 1.0 X-Received: by 10.224.53.196 with SMTP id n4mr4104941qag.104.1377637089108; Tue, 27 Aug 2013 13:58:09 -0700 (PDT) Received: by 10.224.60.137 with HTTP; Tue, 27 Aug 2013 13:58:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Aug 2013 13:58:09 -0700 Message-ID: From: Dave Taht To: Naeem Khademi Content-Type: multipart/alternative; boundary=001a1133dde05367db04e4f4218a Cc: Eric Dumazet , bloat Subject: Re: [Bloat] SFQRED or SFQARED? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:58:10 -0000 --001a1133dde05367db04e4f4218a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2013 at 1:44 PM, Dave Taht wrote: > > > > On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi w= rote: > >> Hi >> >> Slide 37 of below link mentions that SFQRED implemented in Linux 3.4 >> upwards, "Utilized a better version of RED (=93ARED=94) from Sally Floyd >> in 2002". However I'm unable to find the "adaptive" bit of SFQRED in >> the kernel and iproute code. Can anyone (Dave or Eric) confirm that >> the mentioned statement is correct? >> >> http://netseminar.stanford.edu/seminars/Inside_Codel_and_Fq_Codel.pdf >> >> > I think you are correct in that the adaptive RED code never formally made > it into SFQRED. SFQRED was a brief blip in time before codel showed up... > I'd talked about it in that talk as a steppingstone in hybrid fq+aqm > history. (prior to that we were working with qfq + red as entirely > separate, modular qdiscs). So... oops. > While I'm correcting slides and trying to keep history straight, after that talk it was pointed out that head drop from the biggest flow had been proposed as early as 1999, and possibly as early as the mid-late 1980s... https://lists.bufferbloat.net/pipermail/bloat/2013-February/001345.html I enjoyed the literature search around that thread a lot. What was new was old again. > I think the work was interesting and valuable, and if you want to play > with the ARED variant probably all you have to do is OR in the > TC_ADAPTATIVE value into the flags on the red setup in sch_sfq.c > > Eric added ARED support to sch_red in kernel commit: > 8af2a218de38f51ea4b4fa48cac1273319ae260c > > > https://android.googlesource.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48= cac1273319ae260c > > and some ip route version later corrected "adaptive" to be the user-facin= g > syntax. I just ran a quick, dirty and (nonsensical*) rrul test with this: > > tc qdisc add dev eth0 root red limit 40000 min 30000 max 90000 avpkt 1000 > burst 55 ecn adaptive bandwidth 10Mbit > > tc -s qdisc show dev eth0 > qdisc red 8005: root refcnt 2 limit 40000b min 30000b max 90000b ecn > adaptive > Sent 858913226 bytes 823269 pkt (dropped 4866, overlimits 123 requeues 0= ) > backlog 0b 0p requeues 0 > marked 0 early 123 pdrop 4743 other 0 > > which "just worked" with ubuntu 13.4. > > The ARED option could be enabled with GRED/SFQRED with adding the right > knob to iproute2. > > > Regards, >> Naeem >> > > > * I have thankfully managed to completely forget how to configure RED or > ARED to what little extent I understood it in the first place > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --001a1133dde05367db04e4f4218a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 27, 2013 at 1:44 PM, Dave Taht <dave.taht@gmail.com<= /a>> wrote:



On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi &l= t;naeem.khadem= i@gmail.com> wrote:
Hi

Slide 37 of below link mentions that SFQRED implemented in Linux 3.4
upwards, "Utilized a better version of RED (=93ARED=94) from Sally Flo= yd
in 2002". However I'm unable to find the "adaptive" bit = of SFQRED in
the kernel and iproute code. Can anyone (Dave or Eric) confirm that
the mentioned statement is correct?

http://netseminar.stanford.edu/seminars/Inside_Cod= el_and_Fq_Codel.pdf


I think you are correct in= that the adaptive RED code never formally made it into SFQRED. SFQRED was = a brief blip in time before codel showed up... I'd talked about it in t= hat talk as a steppingstone in hybrid fq+aqm history. (prior to that we wer= e working with qfq + red as entirely separate, modular qdiscs). So... oops.=

While I'm corr= ecting slides and trying to keep history straight, after that talk it was p= ointed out that head drop from the biggest flow had been proposed as early = as 1999, and possibly as early as the mid-late 1980s...

https://lists.bufferbloat.net/pipermail/bloat/2013-February/00= 1345.html

I enjoyed the literature search around that= thread a lot. What was new was old again.


I think the work was interesting and valuable, and if you want to play = with the ARED variant probably all you have to do is OR in the TC_ADAPTATIV= E value into the flags on the red setup in sch_sfq.c

Eric added ARED support to sch_red in kernel commit: 8af2a218de38f51ea4b4fa= 48cac1273319ae260c

http= s://android.googlesource.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48cac127= 3319ae260c

and some ip route version later corrected "adaptive" to be th= e user-facing syntax. I just ran a quick, dirty and (nonsensical*) rrul tes= t with this:

tc qdisc add dev eth0 root red limit 40000 min 30000 ma= x 90000 avpkt 1000 burst 55 ecn adaptive bandwidth 10Mbit

tc -s qdisc show dev eth0
qdisc red 8005: root refcnt 2 limit 40000b= min 30000b max 90000b ecn adaptive
=A0Sent 858913226 bytes 823269 pkt = (dropped 4866, overlimits 123 requeues 0)
=A0backlog 0b 0p requeues 0 <= br> =A0 marked 0 early 123 pdrop 4743 other 0

which "jus= t worked" with ubuntu 13.4.

The ARED option could be= enabled with GRED/SFQRED with adding the right knob to iproute2.


Regards,
Naeem


*= I have thankfully managed to completely forget how to configure RED or ARE= D to what little extent I understood it in the first place=
--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.tek= libre.com/cerowrt/subscribe.html=20



--
Dave T=E4ht

Fixi= ng bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.ht= ml=20 --001a1133dde05367db04e4f4218a--