[Olsr-users] Question about hidden node behavior

[Markus Kittenberger]

hmm, i hope i do not write too much bulls*t in this mail, as i`m not
extremely fit regarding wifi driver internals,.
so please: anyone with more knowledge, shout out *G

On Sun, Jan 9, 2011 at 3:37 PM, ZioPRoTo (Saverio Proto) <(spam-protected)
> wrote:

>
>
usually the buffer of the card is
> 1 or 2 packets.

as long as the buffer is fifo, its size does not matter,..

> What you do with the Linux kernel is doing the queing
> and the ordering before passing the packets to the 802.11 device.
>
again: you can write tc scripts without having to set up a bandwidth,.. (but
see below,.. *G)

> The bandwitdth you set up in the tc script is the rate that your
> kernel will send packets to the device, assuming that device will
> always be able to deliver those packets without losses.
>
hmm above is correct, but does not explain why QoS will not work,..

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)

the problem with some/many wifi interfaces/drivers, is that they tend to lie
regarding this.,..

and without any congestion feedback (refused packets), only qdiscs with
fixed bandwith (as they will drop before the interface is congested) will
work,..

>
> Yes, you can queue first OLSR packets, and send then to the device,
> but if there is no bandwidth the prioritized packets will die in the
> air, so what is the sense of this ?
>
imho it will not die in the air *G

i assume the "priorized-by-kernel" packets are killed by the wireless driver
(in his own queues) or in the hardware queues, ...

>
> So, to do QoS, you MUST know what is the available bandwitdh.
>
not necesarrily!

if you have an wifi driver/hardware that does not do its own
reordering/dropping, QoS will work! (without any need for bandwidth
knowledge)

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,..)

but yes, with atheros hardware this will (usually) not work,..
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!)
<zynic>and to resolve this, i guess 802.11e was "invented" *G</zynic>

of course this rescheduling enables this wifi drivers/hardware to do some
nice (wireless specific) things (like power save features),

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,..

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110111/9a3354ad/attachment.html>