This is a plot of applying queue management on top of the existing
queue structure, only one queue active, against 50 saturating streams
against a voip-like ping.

http://www.teklibre.com/~d/bloat/ping_log.ps

To explain it the first part of the plot is the start of the test,
the second part is after a brief, small rate change downwards, the
drop to 0 is the end of the first test, then it goes back and starts
another.

While the clustering at the ~60-90ms line is good and due to sfqred
doing it's job, it's connected to and unable to control the large,
floppy rubber hose of buffering beneath it, translating out to ~100ms
of jitter on more normal spiky loads under good conditions and worse
on bad.

A flaw of this particular plot is it measures intrinsic buffering on
both sides of the connection, but it's still a lot of intrinsic
latency. It would be nice to be able to apply BQL or BQL-like
techniques to this, because that white space underneath the plot gets
much more latent at lower rates.

On Mon, Feb 27, 2012 at 4:10 PM, Dave Taht [off-list ref] wrote:

On Mon, Feb 27, 2012 at 12:49 PM, Johannes Berg
[off-list ref] wrote:

quoted

As a consequence, I'm thinking that we should redesign the mac80211 /
driver queue API to mirror more closely the kind of queues hardware
really has.

I'd like the driver queues to mirror more closely the kinds of
connections the hardware really has. I realize that this is more of an
AP orientation than a wireless client orientation, but with wildly
different rates between connected devices bad things happen.

Secondly, my take on 802.11e QoS and wireless-n aggregation is that
aggregation wins nearly every time; all
802.11e does is bloat up the buffers.

quoted

To recap: today, almost all drivers expose four queues to mac80211 for
the four ACs. In reality, many have many more queues, e.g. in iwlwifi:
 * 4 for the first vif
 * 4 for the second vif
 * 1 for CAB (content after [DTIM] beacon)
 * 1 for off-channel

They are mapped as follows:
 * all vif ACs -> 4 ACs
 * off-channel -> BE
 * CAB         -> BE (I believe, maybe all?)

Thus when e.g. in our driver the BE queue for the second VIF is full, we
stop all traffic across all VIFs. When both VIFs are on the same
channel, this isn't really a problem. However, when they are on
different channels, there could be vastly different performance
characteristics on those two channels due to interference etc.

And even more differences based on the destination's characteristics.




--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net