Le jeudi 01 décembre 2011 à 22:35 +0100, Dave Taht a écrit :

On Thu, Dec 1, 2011 at 10:06 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le mercredi 30 novembre 2011 à 14:36 -0800, Stephen Hemminger a écrit :

quoted

(Almost) nobody uses RED because they can't figure it out.
According to Wikipedia, VJ says that:
 "there are not one, but two bugs in classic RED."

Heh. "There were not two, but four bugs in Linux red".

Now reduced to 2. :)

This story about VJ and bugs in classic RED is urban legend if you ask
me :)

RED is useful for high throughput routers, I doubt many linux machines

quoted

act as such devices.

"High throughput" at the time red was designed was not much faster
than a T1 line.

RED appears to be used by default in both gargoyle's and openwrt's QoS systems,
underneath unholy combinations of HTB, HSFC, and SFQ
so it's more widely used than you might think. Not that works well.

RED doesn't work worth beans on variable bandwidth links (cable
modems/wireless).

Adaptative RED is the answer

Once you are simulating a fixed rate link (e.g with HTB), then it sort of
kinda maybe can apply.

RED was also designed at a time when long distance traffic was fixed rate
and bidirectional, so the 'average packet' parameter made sense.
Modern day traffic is far more asymmetric.

The truth is : For RED be effective (with say 20 to 100 flows), you need
a reasonable amount of packets in queue, and low wq (high burst value in
linux), depending on the RTT. And on consumer links (ADSL, cable
modem ...), RTT is quite big.

RED performance is best when the average queue size is estimated over a
small _multiple_ of round-trip times, not over a fraction of a single
round-trip time.

In this respect, your RED setups are pathological (minimum burst value,
meaning wq = 0.5 or so), so in a small fraction of RTT, avgqsz value is
completely changed, so flows have no chance to be able to react
smoothly.