Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: bloat-devel@lists.bufferbloat.net
Subject: Re: [Bloat] Thoughts on Stochastic Fair Blue
Date: Thu, 24 Mar 2011 15:20:03 +0100	[thread overview]
Message-ID: <1300976403.3747.26.camel@edumazet-laptop> (raw)
In-Reply-To: <1EC45925-8DE2-4ABA-83AE-09A8E2290100@gmail.com>

Le jeudi 24 mars 2011 à 15:57 +0200, Jonathan Morton a écrit :
> On 24 Mar, 2011, at 3:44 pm, Dave Taht wrote:
> 
> >> Here is the POC patch I am currently testing, with a probability to
> >> "early drop" a packet of one percent per ms (HZ=1000 here), only if
> >> packet stayed at least 4 ms on queue.
> 
> A fixed time threshold doesn't take into account the wildly varying
> bandwidths of connections.  For example, 4ms will cause almost any
> queued packet on a 33.6K modem uplink (or a 3G or GSM tether) to be
> marked, yet with the 128-packet default size for SFQ, a GigE NIC will
> typically empty the queue before any packets reach the marking
> threshold.
> 

If an ideal value would exist, we would use them, and provide a black
box. On my particular test setup I used 4 ms threshold, thats it.

You cant solve any problems with a single "super qdisc". We provide many
different qdisc (and params) to be able to build complex setups.

DRR for example is nice, because it provides an extensive
infrastructure. SFQ is good only because its space optimized (I know
some setups using 100.000 SFQ qdiscs on a single router)

You might want to play with QFQ, we are about to release it.

> But perhaps a heuristic such as not marking packets which are the last
> in their bucket would be okay, and mark everything else when the queue
> is more than half full.

Mark everything is not good, RED like algo use probabilities.



      reply	other threads:[~2011-03-24 14:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AB70D849-EC48-438E-B009-E22223CAF5E2@gmail.com>
     [not found] ` <7imxklz5vu.fsf@lanthane.pps.jussieu.fr>
     [not found]   ` <160809C8-284C-4463-97FE-0E2F03C08589@gmail.com>
     [not found]     ` <1300973556.3747.9.camel@edumazet-laptop>
2011-03-24 13:44       ` Dave Taht
2011-03-24 13:55         ` Eric Dumazet
2011-03-24 13:57         ` Jonathan Morton
2011-03-24 14:20           ` Eric Dumazet [this message]

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

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

  git send-email \
    --in-reply-to=1300976403.3747.26.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=chromatix99@gmail.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