Re: [Bloat] what I think is wrong with eBDP in debloat-testing

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

On Mon, Nov 7, 2011 at 8:25 PM, John W. Linville <linville@tuxdriver.com>wrote:

> On Mon, Nov 07, 2011 at 08:10:57PM +0100, Dave Taht wrote:
>
> > John was right when he wrote in the initial announcement:
> >
> > "This version runs separate instances of the algorithm for each WMM
> > queue -- I reckon that makes sense. "
> >
> > and it doesn't.
> >
> > "I still ignore HT aggregation, as I'm pretty sure I don't understand
> > how it really effects the issue."
> >
> > Messes it up completely.
>
> So, can I drop that patch from debloat-testing now?  :-)
>
>
Yea, drop it. (also drop the ancient ath9k patch. It was always wrong)

However, the timestamping/ewma/completion components of the idea are good,
although a couple improvements could be made.

1) Getting kernel time is pretty high overhead. And that clock wanders.
There's a nice, handy TSF clock part of every wireless device that is
stabler (I think) and could be used instead. I don't know if all devices
make it independently available from the hardware.

A) exported from the driver up into the mac80211 driver to where a packet
scheduler/classifier (net/sched/whatever) could get at it.

or

B) made available as a separate clocksource using the clocksource API.

and C) tsf timestamp packets on entry to ndo_select_queue before handing
off and up to the scheduler.

Granularity doesn't need to be better than a TU so it doesn't need to read
from the hardware directly every time.
The kernel makes no guarantees about how the clock relates to anything
other than the hardware itself...

In other words, how to get that clock's timestamp up into a place where the
packet scheduler can use it is something of a problem, easily solved,
however getting at that clocksource back at a packet scheduler layer is
mildly harder.

2) Also station id is needed (something more hashable and < 32 bits than a
mac addr) AND a few fields from minstrel's per-sta info - which is really
hard to get at on a per packet basis, as it's under a rcu)

Felix and I discussed starting to wedge a structure into the otherwise
mostly unused 'user-defined' 48 byte space in a skb in that section of the
mac80211 code and I kind of prefer to just add more fields to the bql
stuff... if I knew what they all were. Which I don't.

3) Completions per station would be a useful abstraction to have also
wedged into that structure...




> --
> John W. Linville                Someday the world will need a hero, and you
> linville@tuxdriver.com                  might be all we have.  Be ready.
>



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

[-- Attachment #2: Type: text/html, Size: 3568 bytes --]