[Bloat] Thoughts on Stochastic Fair Blue

Eric Dumazet eric.dumazet at gmail.com
Thu Mar 24 10:20:03 EDT 2011


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.





More information about the Bloat-devel mailing list