From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (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 AFE4C201B88 for ; Tue, 27 Aug 2013 13:44:17 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id k8so1681484qcq.28 for ; Tue, 27 Aug 2013 13:44:16 -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=4SMcB1tCvqI7lP8ZwO4wWuWGpgBXXlW/uGiq1csUovw=; b=t2F/LI0Y/LgIxvg0FJOVap1EmoKqk6nYQH2Uak+HlZ4uaR4YVZW/Hi0MAM4X+7M0Um Tg2ZsU44x+9ThXTaFQdRIX8IoYdioB1c51gmp5hbcgrU8KZk/6i7mIRZPMe9ftU5OP5c m+vEDmwmx/vK41jHEtg+W9MisRREnbl97DBNJVp/i+UTGCSmRZ98oFxLj8otJOJXxwGT IFS+lFKZVamT61sQroVNOgdlUxCJxaov5O8Ta34XOtLbDNF3dmoxVrv8g89I8ejxzZMm 3B1pU+hiZwuWV1IZwtbEhoNBcpaCUMDQFK/qXIVEsuxU0uNeGmlzDJkP6OEMdl6Fe53e RO1g== MIME-Version: 1.0 X-Received: by 10.49.52.41 with SMTP id q9mr13394077qeo.32.1377636256613; Tue, 27 Aug 2013 13:44:16 -0700 (PDT) Received: by 10.224.60.137 with HTTP; Tue, 27 Aug 2013 13:44:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Aug 2013 13:44:16 -0700 Message-ID: From: Dave Taht To: Naeem Khademi Content-Type: multipart/alternative; boundary=047d7bea3f3cb4a78e04e4f3efd1 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:44:18 -0000 --047d7bea3f3cb4a78e04e4f3efd1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi wro= te: > 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. 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/+/8af2a218de38f51ea4b4fa48ca= c1273319ae260c and some ip route version later corrected "adaptive" to be the user-facing 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 --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --047d7bea3f3cb4a78e04e4f3efd1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



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 ad= aptive 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 wi= th qfq + red as entirely separate, modular qdiscs). So... oops.

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

https://android.google= source.com/kernel/exynos/+/8af2a218de38f51ea4b4fa48cac1273319ae260c

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
--047d7bea3f3cb4a78e04e4f3efd1--