[Olsr-users] Fwd: Question about hidden node behavior

[Mitar]

Hi!

Nick's reply.


Mitar

---------- Forwarded message ----------
From: Nick Kossifidis <(spam-protected)>
Date: Thu, Jan 13, 2011 at 12:22 AM
Subject: Re: [Olsr-users] Question about hidden node behavior
To: Mitar <(spam-protected)>


Ath5k/ath9k handle hw queues, that means they have 4+1 hw queues (with
a few hundred buffers pre-allocated) that are configured by the driver
and mac80211 fills them and "wakes" them up (beacon queue is triggered
by an interrupt). If a hw queue is filled at the driver level we have
to drop packets or else we 'll have memory/performance problems. So
far i haven't seen a hw queue filled, they are emptied really fast,
not even on multi-bssid scenarios, if a hw queue is filled you'll get
a warning on dmesg

from ath5k's base.c
1563                 ATH5K_ERR(sc, "no further txbuf available,
dropping packet\n");

2011/1/12 Mitar <(spam-protected)>:
> Hi!
>
> Does ath5k/9k report to the kernel, when it gets filled?
>
>
> Mitar
>
> ---------- Forwarded message ----------
> From: Markus Kittenberger <(spam-protected)>
> Date: Tue, Jan 11, 2011 at 2:58 PM
> Subject: Re: [Olsr-users] Question about hidden node behavior
> To: "ZioPRoTo (Saverio Proto)" <(spam-protected)>
> Cc: Mitar <(spam-protected)>, olsr-users users
> <(spam-protected)>, Tomaz Toplak <(spam-protected)>
>
>
>
> 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
>



--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick