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 <dave.taht@xxxxxxxxx> wrote: > On Mon, Feb 27, 2012 at 12:49 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > >> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
