<br><br><div class="gmail_quote">On Thu, Jan 13, 2011 at 11:19 PM, Markus Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div> </div><div class="gmail_quote"><div>if i find time next week, i will definetly run my QoS test-scripts against ath5k and ath9k aswell<br><br></div><div>and i`m quite optimistic that it will work,.. (and if not i`ll let u know *G)</div>
</div></blockquote><div><br></div><div>i just tested ath5k and ath9k,..</div><div><br></div><div>and ath5k works exactly like it should,..<br>but ath9k behaves only somewhat better as madwifi, but defintely not as it should,..<br>
</div><div><br></div><div>or in numbers,..</div><div>i had 3 udp streams with 5mbit txrate running against a wireless link with 5.5mbit bitrate (4mbit netto udp throughput)</div><div><br></div><div><div>this 3 streams where classified into the 3 queues of a prio qdisc,..</div>
<div>(so the result should be 4mbit for the traffic classified into first queue and nothing for other traffic)</div><div><br></div></div><div>without any QoS rule active on all tested drivers/wifi-hardware each stream got ~ 1.3mbit<br>
<br></div><div>results with QoS:<br>q1  q2  q3 driver<br>4.0 0.0 0.0 b43-legacy<br>4.0 0.0 0.0 ath5k (pci)<br>2.5 1.5 0.0 ath9k (pci)<br>1.3 1.3 1.3 madwifi (ahb)<br></div><div><br></div><div>Markus</div></div>