CoDel AQM discussions
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Tomas Hruby <thruby@google.com>,
	Nandita Dukkipati <nanditad@google.com>,
	netdev <netdev@vger.kernel.org>,
	codel@lists.bufferbloat.net
Subject: Re: [Codel] [RFC v2] fq_codel : interval servo on hosts
Date: Tue, 4 Sep 2012 09:40:40 -0700	[thread overview]
Message-ID: <CAA93jw6k4pgwanTa81oHb8jV6WGMfoo6KuOBSjbrfU3eRMbt5A@mail.gmail.com> (raw)
In-Reply-To: <1346772855.13121.40.camel@edumazet-glaptop>

On Tue, Sep 4, 2012 at 8:34 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-09-04 at 08:10 -0700, Nandita Dukkipati wrote:
>> The idea of using srtt as interval makes sense to me if alongside we
>> also hash flows with similar RTTs into same bucket. But with just the
>> change in interval, I am not sure how codel is expected to behave.
>>
>> My understanding is: the interval (usually set to worst case expected
>> RTT) is used to measure the standing queue or the "bad" queue. Suppose
>> 1ms and 100ms RTT flows get hashed to same bucket, then the interval
>> with this patch will flip flop between 1ms and 100ms. How is this
>> expected to measure a standing queue? In fact I think the 1ms flow may
>> land up measuring the burstiness or the "good" queue created by the
>> long RTT flows, and this isn't desirable.

Experiments would be good.

>
> Well, how things settle with a pure codel, mixing flows of very
> different RTT then ?

Elephants are shot statistically more often than mice.

> It seems there is a high resistance on SFQ/fq_codel model because of the
> probabilities of flows sharing a bucket.

I was going to do this in a separate email, because it is a little off-topic.

fq_codel has a standing queue problem, based on the fact that when a
queue empties, codel.h resets. This made sense for the single FIFO
codel but not multi-queued fq_codel. So after we hit X high rate
flows, target can never be achieved, even straining mightily, and we
end up with a standing queue again.

Easily seen with like 150 bidirectional flows at 10 or 100Mbit.

(as queues go, it's still pretty good queue. And: I've fiddled with
various means of draining multi-queue behavior thus far, and they
ended up unstable/unfair)

> So what about removing the stochastic thing and switch to a hash with
> collision resolution ?

Was considered and discarded in the original SFQ paper as being too
computationally intensive
(in 1993). Worth revisiting.

http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf

>
>



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
with fq_codel!"

  reply	other threads:[~2012-09-04 16:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-31  6:55 [Codel] fq_codel : interval servo Eric Dumazet
2012-08-31 13:41 ` Jim Gettys
2012-08-31 13:50 ` [Codel] [RFC] fq_codel : interval servo on hosts Eric Dumazet
2012-08-31 13:57   ` [Codel] [RFC v2] " Eric Dumazet
2012-09-01  1:37     ` Yuchung Cheng
2012-09-01 12:51       ` Eric Dumazet
2012-09-04 15:10         ` Nandita Dukkipati
2012-09-04 15:25           ` Jonathan Morton
2012-09-04 15:39             ` Eric Dumazet
2012-09-04 15:34           ` Eric Dumazet
2012-09-04 16:40             ` Dave Taht [this message]
2012-09-04 16:54               ` Eric Dumazet
2012-09-04 16:57               ` Eric Dumazet
2012-08-31 15:53 ` [Codel] fq_codel : interval servo Rick Jones
2012-08-31 16:23   ` Eric Dumazet
2012-08-31 16:59     ` Dave Taht
2012-09-01 12:53       ` Eric Dumazet
2012-09-02 18:08         ` Dave Taht
2012-09-02 18:17           ` Dave Taht
2012-09-02 23:28             ` Eric Dumazet
2012-09-02 23:23           ` Eric Dumazet
2012-09-03  0:18             ` Dave Taht
2012-08-31 16:40   ` Jim Gettys
2012-08-31 16:49     ` Jonathan Morton
2012-08-31 17:15       ` Jim Gettys
2012-08-31 17:31         ` Rick Jones
2012-08-31 17:44           ` Jim Gettys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw6k4pgwanTa81oHb8jV6WGMfoo6KuOBSjbrfU3eRMbt5A@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=eric.dumazet@gmail.com \
    --cc=nanditad@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=thruby@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox