[RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat

[Dave Täht]

Jim Gettys <jg at freedesktop.org> writes:

> On 02/19/2011 07:37 PM, Nathaniel Smith wrote:
>> Actually, a few more comments just occurred to me...
>>
>> On Fri, Feb 18, 2011 at 1:21 PM, John W. Linville
>> <linville at tuxdriver.com>  wrote:
>>> Johannes' comment about tx status reporting being unreliable (and what
>>> he was really saying) finally sunk-in.  So, this version uses
>>> skb->destructor to track in-flight fragments.  That should handle
>>> fragments that get silently dropped in the driver for whatever reason
>>> without leaking queue capacity.  Correct me if I'm wrong!
>>
>> Should we be somehow filtering out and ignoring the packets that get
>> dropped, when we're calculating the average packet transmission rate?
>> Presumably they're getting dropped almost instantly, so they don't
>> really take up queue space and they have abnormally fast transmission
>> times, which will tend to cause us to overestimate max_enqueued? They
>> should be rare, though, at least. (And presumably we *should* include
>> packets that get dropped because their retry timer ran out, since they
>> were sitting in the queue for that long.) Possibly we should just
>> ignore any packet that was handled in less than, oh, say, a few
>> microseconds?

The perfect is the enemy of the good. POGE[1] applies. After getting 2
orders of magnitude improvement with the patches thus far...

My reaction to the above is that I'd like to get what is being
implemented tested by more folk, across more drivers. Me being one of
them! I hope to get builds done today for several openwrt devices and my
laggy-lagn laptop. 

> I will note that AQM algorithms that are likely to work will need to
> know the actual "goodput" of the link. (This from talking to Van
> Jacobson about the problem we face.)

I care about AQM, I really do[2]... Certainly exposing more hooks and data
to the next layer in the stack from the driver would be good... But I'd
like mostly simply to get:

A) People using and loving debloated drivers, & more people aware of and
fixing the problem...

B) The dynamic range available via ethtool to userspace to be vastly
increased

C) Buffer sizes defaulting to much less, across the board.

These are the simplest, most effective, low hanging fruit/fixes. [1]

We're making great progress on wireless, how do we make progress on wired?

-- 
Dave Taht
http://nex-6.taht.net

1: http://en.wikipedia.org/wiki/Principle_of_good_enough
2: I'll patch SFB into my build and any other of the new AQMs
   anyone can suggest