Bemused to

[Felix Fietkau]

On 2011-02-14 3:01 AM, Dave Täht wrote:
> 
> Felix:
> 
> ReSend your original also to bloat-devel at lists.bufferbloat.net ?
Cc'd.

> I'm editing down our chat now... Will respond in more detail after I
> review my notes there. You might also want to talk to Jean Tourrilhes
> 
> https://lists.bufferbloat.net/pipermail/bloat/2011-February/thread.html
> 
> 
> Felix Fietkau <nbd at openwrt.org> writes:
> 
>> Hi Nathaniel, Dave,
>>
>> I'm currently trying to work out a way to combat the bufferbloat issue
>> in ath9k, while still ensuring that aggregation does its job to reduce
>> airtime utilization properly.
> 
> It would help me if you could describe the current math behind how
> airtime utilization works in n. I know how aggregation works - and like it -
> but the timeslots used in 802.11n are part of a twisty maze of
> standards, all different. 
> 
> Pretend I've (and the others on the list) have been living on the moon
> for a couple years.
The timeslot maze in 802.11n is pretty much the same as with 802.11a/g,
I don't have a good description about it, but since there are so many
environment factors that play into it as well, I usually just treat it
as an unpredictable source of wildly fluctuating extra latency and move on.

>> The nice thing about ath9k compared to Intel drivers is that all of the
>> aggregation related queueing is done inside the driver instead of some
>> opaque hardware queue or firmware. That allows me to be more selective
>> in which packets to drop and which ones to keep.
> 
> I found the lagn driver to be, well, laggy. 
> 
>> One thing that I need to ensure (based on requirements of some
>> commercial projects that I'm working on) is that bufferbloat
>> countermeasures must not hurt maximum TCP throughput when testing under
>> ideal conditions. Considering the flexibility of being able to work
>> directly on an aggregation queueing level, this should not be much of a
>> problem, IMHO.
> 
> I'd like a knob that users could use to tune for better
> interactivity. One knob for benchmarks, one for users that like to do
> voip and play quake, one knob to rule them all, and the dark buffers
> bind them. 
Tunables are good, but I think for this to work properly we need very
solid defaults.

>> I'm currently trying to come up with some good functions to determine at
>> which point packets should be dropped. These will probably have to be
>> different for the software aggregation queues compared to the default
>> WMM hardware queues where legacy frames are queued up directly.
>>
>> For aggregation I would like to allow at least the maximum number of
>> packets that can fit into one A-MPDU, which depends on the selected
>> rate. Since wireless driver queueing will really only have an effect
>> when we're running short on airtime, we need to make sure that we reduce
>> airtime waste caused by PHY headers, interframe spacing, etc.
>> A-MPDU is a very neat way to do that...
>>
>> Do you have any good suggestions about the implementaton of the queue
>> length vs measured latency relationship, or anything else that I should
>> take into account?
> 
> I've found in my testing, that TCP vegas is interacting badly with the
> levels of buffering and delay in the current ath9k driver, by a lot, so
> it's assumptions are invalid. I know that's of little help.
Yeah, ath9k currently does way too much buffering for its own good,
that's mostly because the aggregation logic is tied closely to hardware
buffer management (i.e. a frame gets a descriptor long before it enters
the hardware queue for the first time). I've been planning to fix that
for a while, and I will eventually get around to it, but it requires
quite a bit of code refactoring.

First step is to decouple the aggregation logic from the internal
descriptors/buffer entries to have more flexible buffer management,
later on I intend to move the aggregation logic to mac80211, where it's
closer to things that happen in the network stack. This will also allow
at least some of the other 802.11n drivers to leverage fixes being done
to this.

- Felix