General list for discussing Bufferbloat
 help / color / mirror / Atom feed
* [Bloat] SFQRED or SFQARED?
@ 2013-08-27 16:29 Naeem Khademi
  2013-08-27 20:44 ` Dave Taht
  0 siblings, 1 reply; 5+ messages in thread
From: Naeem Khademi @ 2013-08-27 16:29 UTC (permalink / raw)
  To: Dave Taht, bloat, edumazet

Hi

Slide 37 of below link mentions that SFQRED implemented in Linux 3.4
upwards, "Utilized a better version of RED (“ARED”) 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

Regards,
Naeem

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bloat] SFQRED or SFQARED?
  2013-08-27 16:29 [Bloat] SFQRED or SFQARED? Naeem Khademi
@ 2013-08-27 20:44 ` Dave Taht
  2013-08-27 20:58   ` Dave Taht
  2013-09-03 17:39   ` Naeem Khademi
  0 siblings, 2 replies; 5+ messages in thread
From: Dave Taht @ 2013-08-27 20:44 UTC (permalink / raw)
  To: Naeem Khademi; +Cc: Eric Dumazet, bloat

[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]

On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi <naeem.khademi@gmail.com>wrote:

> Hi
>
> Slide 37 of below link mentions that SFQRED implemented in Linux 3.4
> upwards, "Utilized a better version of RED (“ARED”) 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/+/8af2a218de38f51ea4b4fa48cac1273319ae260c

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
-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 3175 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bloat] SFQRED or SFQARED?
  2013-08-27 20:44 ` Dave Taht
@ 2013-08-27 20:58   ` Dave Taht
  2013-09-03 18:31     ` Dave Taht
  2013-09-03 17:39   ` Naeem Khademi
  1 sibling, 1 reply; 5+ messages in thread
From: Dave Taht @ 2013-08-27 20:58 UTC (permalink / raw)
  To: Naeem Khademi; +Cc: Eric Dumazet, bloat

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

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

>
>
>
> On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi <naeem.khademi@gmail.com>wrote:
>
>> Hi
>>
>> Slide 37 of below link mentions that SFQRED implemented in Linux 3.4
>> upwards, "Utilized a better version of RED (“ARED”) 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/+/8af2a218de38f51ea4b4fa48cac1273319ae260c
>
> 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
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 4712 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bloat] SFQRED or SFQARED?
  2013-08-27 20:44 ` Dave Taht
  2013-08-27 20:58   ` Dave Taht
@ 2013-09-03 17:39   ` Naeem Khademi
  1 sibling, 0 replies; 5+ messages in thread
From: Naeem Khademi @ 2013-09-03 17:39 UTC (permalink / raw)
  To: Dave Taht; +Cc: Eric Dumazet, bloat

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

>
> 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.
>

Thanks for clarification, so the answer is "no".


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

I'm not completely sure about this, but I'll give it a try and thanks for
the hint.

Cheers,
Naeem

[-- Attachment #2: Type: text/html, Size: 1414 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bloat] SFQRED or SFQARED?
  2013-08-27 20:58   ` Dave Taht
@ 2013-09-03 18:31     ` Dave Taht
  0 siblings, 0 replies; 5+ messages in thread
From: Dave Taht @ 2013-09-03 18:31 UTC (permalink / raw)
  To: Naeem Khademi; +Cc: Eric Dumazet, bloat

[-- Attachment #1: Type: text/plain, Size: 4900 bytes --]

And while I look over this very old, first presentation at stanford that
tried to describe codel and fq_codel, I see multiple places that we have
since improved.

1) I have fallen back to saying that instead of TCP-friendly, codel is
"RTT-friendly". There's not a good definition of this latter phrase. Matt
Mathis suggests I use "window friendly" instead, but I try to think of
"RTT-friendly" as "waiting long enough for a congestion signal to reach the
other side" and entirely outside of a tcp context... could use a harder
definition....

2) My waving hands talking about 1/(sqrt(count) being the inverse of tcp's
increases has since been dropped. I still wish we had a better graphic
explaining what really goes on than I have in that preso, it requires a lot
of talking still to explain it....

3) we have sfq and drr based versions of "fq_codel" in ns2. I've long
encouraged QFQ's author to try the same thing (and qfq + codel can be
easily played with using the debloat script, but you rapidly run out of
memory on teeny routers). There is hfsc + codel in freebsd now (as well as
their fairq variant that I don't know anything about.) I have a couple
variants of codel and fq_codel in patch form and in cerowrt... as well as a
pie still in progress...

Shapers are using (htb or hfsc) + fq_codel... in shapers where people were
using sfq and/or red before. I frankly do not understand hfsc well enough
to say if this is a good idea.

4) And the ever prolific edumazet's pure (non-stochastic) fq just appeared
in net-next with some very interesting and useful properties as to
informing the queue about the host tcp behaviors...

http://marc.info/?l=linux-netdev&m=137781660312650&w=2

(but no codel)

Lots of fun stuff going on!

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

>
>
>
> On Tue, Aug 27, 2013 at 1:44 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:29 AM, Naeem Khademi <naeem.khademi@gmail.com>wrote:
>>
>>> Hi
>>>
>>> Slide 37 of below link mentions that SFQRED implemented in Linux 3.4
>>> upwards, "Utilized a better version of RED (“ARED”) 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/+/8af2a218de38f51ea4b4fa48cac1273319ae260c
>>
>> 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
>>  --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 7564 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-09-03 18:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-27 16:29 [Bloat] SFQRED or SFQARED? Naeem Khademi
2013-08-27 20:44 ` Dave Taht
2013-08-27 20:58   ` Dave Taht
2013-09-03 18:31     ` Dave Taht
2013-09-03 17:39   ` Naeem Khademi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox