<br><div class="gmail_quote">On Tue, Jan 18, 2011 at 4:32 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl">teco@inf-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
802.11e provides QoS support for apps that cannot tolerate jitter. </blockquote><div>sure, but this should not "kill" other QoS scenarious,..</div><div><br></div><div>especially ones that work on other hardware and even other drivers for the same hardware,.. *G</div>
<div><br></div><div>as afaik ath5k/ath9k provide backpressure and 802.11e aswell.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This<br>
works nice for for example a scenario where nodes A and C has a bulk flow,<br>
that has negative influence on real time flow between B and D, on same channel.<br>
Packet scheduling at higher layers cannot provide such class of QoS function,<br></blockquote><div>provided a small queue, higher layers wouldn't perform "significantly" worse,.. </div><div><br></div><div>but ACK having a QoS aware harware & driver is defintely good!</div>
<div>(but it should extend overall QoS possibilities, and not limit them,..)</div><div><br></div><div>Markus</div></div>