<div><br></div><div>hmm, i hope i do not write too much bulls*t in this mail, as i`m not extremely fit regarding wifi driver internals,.<br></div><div>so please: anyone with more knowledge, shout out *G</div><br><div class="gmail_quote">
On Sun, Jan 9, 2011 at 3:37 PM, ZioPRoTo (Saverio Proto) <span dir="ltr"><<a href="mailto:zioproto@gmail.com">zioproto@gmail.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"> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">usually the buffer of the card is<br>
1 or 2 packets. </blockquote><div>as long as the buffer is fifo, its size does not matter,.. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What you do with the Linux kernel is doing the queing<br>

and the ordering before passing the packets to the 802.11 device.<br></blockquote><div>again: you can write tc scripts without having to set up a bandwidth,.. (but see below,.. *G)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

The bandwitdth you set up in the tc script is the rate that your<br>
kernel will send packets to the device, assuming that device will<br>
always be able to deliver those packets without losses.<br></blockquote><div>hmm above is correct, but does not explain why QoS will not work,.. </div><div><br></div><div>imho the kernel also expects/assumes an (ethernet-like) interface to either accept a packet, or to refuses it, (cause its interface buffer is still full)<br>
<br></div><div>the problem with some/many wifi interfaces/drivers, is that they tend to lie regarding this.,..</div><div><br></div><div>and without any congestion feedback (refused packets), only qdiscs with fixed bandwith (as they will drop before the interface is congested) will work,..</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Yes, you can queue first OLSR packets, and send then to the device,<br>
but if there is no bandwidth the prioritized packets will die in the<br>
air, so what is the sense of this ?<br></blockquote><div>imho it will not die in the air *G</div><div><br></div><div>i assume the "priorized-by-kernel" packets are killed by the wireless driver (in his own queues) or in the hardware queues, ... </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
So, to do QoS, you MUST know what is the available bandwitdh.<br></blockquote><div>not necesarrily!</div><div><br></div><div>if you have an wifi driver/hardware that does not do its own reordering/dropping, QoS will work! (without any need for bandwidth knowledge)</div>
<div><br></div><div>e.g. on a WRT54gl (running openwrt whiterussian) you can defintely use for example a PRIO queue, to let the kernel reorder packets, and as soon as the wifi interface is congested, the kernel queues fill up, and then the kernel will drop packets from lower PRIO subqueues, ... (and we get a working QoS that selfadapts to available bandwidth,..)</div>
<div><br></div><div>but yes, with atheros hardware this will (usually) not work,..</div><div>as the wifi driver does not to really report congestion back to the kernel and seems to reschedule and drop packets itself. (imho rescheduling alone would be just a bit nasty, but dropping is really bad!) </div>
<div><zynic>and to resolve this, i guess 802.11e was "invented" *G</zynic></div><div><br></div><div>of course this rescheduling enables this wifi drivers/hardware to do some nice (wireless specific) things (like power save features),</div>
<div><br></div><div>but regarding QoS i think this behaviour "just sucks", especially as i do not know of (m)any benefits (of this wifi-driver internal queuing) in adhoc mode,..</div><div><br></div><div>Markus</div>
</div>