<br><br><div class="gmail_quote">On Mon, Nov 7, 2011 at 8:25 PM, John W. Linville <span dir="ltr"><<a href="mailto:linville@tuxdriver.com">linville@tuxdriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Nov 07, 2011 at 08:10:57PM +0100, Dave Taht wrote:<br>
<br>
> John was right when he wrote in the initial announcement:<br>
><br>
> "This version runs separate instances of the algorithm for each WMM<br>
> queue -- I reckon that makes sense. "<br>
><br>
> and it doesn't.<br>
><br>
> "I still ignore HT aggregation, as I'm pretty sure I don't understand<br>
> how it really effects the issue."<br>
><br>
> Messes it up completely.<br>
<br>
</div>So, can I drop that patch from debloat-testing now?  :-)<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Yea, drop it. (also drop the ancient ath9k patch. It was always wrong)<br><br>However, the timestamping/ewma/completion components of the idea are good, although a couple improvements could be made.<br>
<br>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. <br>
<br>A) exported from the driver up into the mac80211 driver to where a packet scheduler/classifier (net/sched/whatever) could get at it.<br><br>or<br><br>B) made available as a separate clocksource using the clocksource API.<br>
<br>and C) tsf timestamp packets on entry to ndo_select_queue before handing off and up to the scheduler.<br><br>Granularity doesn't need to be better than a TU so it doesn't need to read from the hardware directly every time.<br>
The kernel makes no guarantees about how the clock relates to anything other than the hardware itself...<br><br>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.<br>
<br>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)<br>
<br>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.<br>
<br>3) Completions per station would be a useful abstraction to have also wedged into that structure...<br><br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<span class="HOEnZb"><font color="#888888">
--<br>
John W. Linville                Someday the world will need a hero, and you<br>
<a href="mailto:linville@tuxdriver.com">linville@tuxdriver.com</a>                  might be all we have.  Be ready.<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br>FR Tel: 0638645374<br><a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a><br>